Do we really need two xl_heap_lock records? - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Do we really need two xl_heap_lock records?
Date
Msg-id CAH2-Wzke2O0ppb9WMB+c8UnmzHMNV_os7an6cLYN8=9Os1t5LQ@mail.gmail.com
Whole thread Raw
List 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

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Note new NULLS NOT DISTINCT on unique index tutorial page
Next
From: David Rowley
Date:
Subject: Re: Note new NULLS NOT DISTINCT on unique index tutorial page