Do we really need two xl_heap_lock records?

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Do we really need two xl_heap_lock records?
Дата
Msg-id CAH2-Wzke2O0ppb9WMB+c8UnmzHMNV_os7an6cLYN8=9Os1t5LQ@mail.gmail.com
обсуждение исходный текст
Список pgsql-hackers
Attached patch removes xl_heap_lock_updated/XLOG_HEAP2_LOCK_UPDATED,
which allows us to throw out about a hundred lines of duplicative
(though hairy) code, net total. The patch also reclaims some Heap2
info bit space, which seems quite useful.

The patch teaches heap_lock_updated_tuple_rec() to make use of the
generic xl_heap_lock/XLOG_HEAP_LOCK record type, rather than using the
now-removed custom record type. My guess is that commit 0ac5ad5134
(where xl_heap_lock_updated originated) simply missed the opportunity
to consolidate the two records into one, perhaps because the patch
evolved a lot during development. Note that xl_heap_lock is already
used by several heapam routines besides heap_lock_tuple (e.g.
heap_update uses it).

Testing with wal_consistency_checking did not demonstrate any problems
with the patch. It's not completely trivial, though. It seems that
there are steps in the REDO routines that shouldn't be performed in
the locked-updated-tuple case -- I had to invent XLH_LOCK_UPDATED to
deal with the issue. There may be a better approach there, but I
haven't thought about it in enough detail to feel confident either
way.

-- 
Peter Geoghegan

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Note new NULLS NOT DISTINCT on unique index tutorial page
Следующее
От: David Rowley
Дата:
Сообщение: Re: Note new NULLS NOT DISTINCT on unique index tutorial page