Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code) - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)
Date
Msg-id 69BFAF9E-91C5-418E-B007-D5B3A97386B3@amazon.com
Whole thread Raw
In response to Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 8/26/20, 12:16 PM, "Alvaro Herrera" <alvherre@2ndquadrant.com> wrote:
> On 2020-Aug-20, Jeremy Schneider wrote:
>> Alternatively, if we don't want to take this approach, then I'd argue
>> that we should update README.tuplock to explicitly state that
>> XMAX_LOCK_ONLY and XMAX_COMMITTED are incompatible (just as it already
>> states for HEAP_XMAX_IS_MULTI and HEAP_XMAX_COMMITTED) and clean up the
>> code in heapam_visibility.c for consistency.
>
> Yeah, I like this approach better for the master branch; not just clean
> up as in remove the cases that handle it, but also actively elog(ERROR)
> if the condition ever occurs (hopefully with some known way to fix the
> problem; maybe by "WITH tup AS (DELETE FROM tab WHERE .. RETURNING *)
> INSERT * INTO tab FROM tup" or similar.)

+1.  I wouldn't mind picking this up, but it might be some time before
I can get to it.

Nathan


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Issue with past commit: Allow fractional input values for integer GUCs ...
Next
From: Anastasia Lubennikova
Date:
Subject: Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits