Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)

Поиск
Список
Период
Сортировка
От Bossart, Nathan
Тема Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)
Дата
Msg-id 69BFAF9E-91C5-418E-B007-D5B3A97386B3@amazon.com
обсуждение исходный текст
Ответ на Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Issue with past commit: Allow fractional input values for integer GUCs ...
Следующее
От: Anastasia Lubennikova
Дата:
Сообщение: Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits