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

From Jeff Janes
Subject Re: SEQUENCE values (duplicated) in some corner cases when crash happens
Date
Msg-id CAMkU=1ya6Wx=2Aq3fn6TjxC6rvmUMPY55ffEXdRV27TMN7cEbg@mail.gmail.com
Whole thread Raw
In response to Re: SEQUENCE values (duplicated) in some corner cases when crashhappens  (Jeremy Schneider <schnjere@amazon.com>)
Responses Re: SEQUENCE values (duplicated) in some corner cases when crash happens  (Jeremy Schneider <schnjere@amazon.com>)
List pgsql-hackers
On Wed, May 6, 2020 at 1:52 PM Jeremy Schneider <schnjere@amazon.com> wrote:
 
The behavior we're observing is that a nextval() call in a committed
transaction is not crash-safe. This was discovered because some
applications were using nextval() to get a guaranteed unique sequence
number [or so they thought], then the application did some processing
with the value and later stored it in a relation of the same database.

The nextval() number was not used until the transaction was committed -

I don't know what this line means.  You said it was stored in a relation, surely that needs to have happened through some command which preceded the commit chronologically, though formally they may have happened atomically.
 
but then the fact of a value being generated, returned and committed was
lost on crash. The nextval() call used in isolation did not seem to
provide durability.

Are you clarifying the original complaint, or this a new, different complaint? Vini's test cases don't include any insertions.  Do you have test cases that can reproduce your complaint?

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: new heapcheck contrib module
Next
From: Jeremy Schneider
Date:
Subject: Re: SEQUENCE values (duplicated) in some corner cases when crash happens