From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "Schneider (AWS), Jeremy" <schnjere(at)amazon(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code) |
Date: | 2020-08-26 21:12:36 |
Message-ID: | 69BFAF9E-91C5-418E-B007-D5B3A97386B3@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8/26/20, 12:16 PM, "Alvaro Herrera" <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Anastasia Lubennikova | 2020-08-26 21:14:34 | Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits |
Previous Message | Tom Lane | 2020-08-26 20:47:43 | Re: Issue with past commit: Allow fractional input values for integer GUCs ... |