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

Jeff Janes <jeff.janes@gmail.com>

From: Jeff Janes <jeff.janes@gmail.com>
To: Jeremy Schneider <schnjere@amazon.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@2ndquadrant.com>, Vinicius Abrahao <vinnix.bsd@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Vinícius Schmidt <vinics@amazon.com>
Date: 2020-05-14T21:58:35Z
Lists: 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