Re: SEQUENCE values (duplicated) in some corner cases when crash happens

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SEQUENCE values (duplicated) in some corner cases when crash happens
Дата
Msg-id 19521.1588183354@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SEQUENCE values (duplicated) in some corner cases when crashhappens  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: SEQUENCE values (duplicated) in some corner cases when crashhappens
Список pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2020-Apr-29, Vinicius Abrahao wrote:
>> I'm opening this thread to clarify something that I can observe: duplicated
>> values for sequences.

> I'm not sure that a sequence that produces the same value twice, without
> writing it to the database the first time, and with an intervening crash
> in between, is necessarily a bug that we care to fix.  Especially so if
> the fix will cause a large performance regression for the normal case
> where the sequence value is written to the DB by a committed transaction.

I believe this behavior is 100% intentional: the advance of the sequence
value is logged to WAL, but we don't guarantee to make the WAL entry
persistent until the calling transaction commits.  And while I'm too
lazy to check right now, I think the calling transaction might've had
to cause some additional non-sequence-object updates to happen on disk,
too, else we won't think it has done anything that needs committing.

As you say, doing something different would entail a large performance
penalty for a rather dubious semantic requirement.  The normal expectation
is that we have to protect sequence values that get written into tables
someplace.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: new heapcheck contrib module
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: xid wraparound danger due to INDEX_CLEANUP false