From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Subject: | Do we really need two xl_heap_lock records? |
Date: | 2023-04-18 03:19:30 |
Message-ID: | CAH2-Wzke2O0ppb9WMB+c8UnmzHMNV_os7an6cLYN8=9Os1t5LQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
v1-0001-Remove-xl_heap_lock_updated-WAL-record.patch | application/octet-stream | 8.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2023-04-18 03:22:36 | Re: Note new NULLS NOT DISTINCT on unique index tutorial page |
Previous Message | David Rowley | 2023-04-18 03:15:19 | Re: Note new NULLS NOT DISTINCT on unique index tutorial page |