On Wed, May 6, 2020 at 1:52 PM Jeremy Schneider <schnj...@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
