Re: SEQUENCE values (duplicated) in some corner cases when crash happens - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SEQUENCE values (duplicated) in some corner cases when crash happens
Date
Msg-id 19521.1588183354@sss.pgh.pa.us
Whole thread Raw
In response to Re: SEQUENCE values (duplicated) in some corner cases when crashhappens  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: SEQUENCE values (duplicated) in some corner cases when crashhappens  (Jeremy Schneider <schnjere@amazon.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: new heapcheck contrib module
Next
From: Peter Geoghegan
Date:
Subject: Re: xid wraparound danger due to INDEX_CLEANUP false