Re: SEQUENCE values (duplicated) in some corner cases when crash happens
| От | Jeff Janes |
|---|---|
| Тема | Re: SEQUENCE values (duplicated) in some corner cases when crash happens |
| Дата | |
| Msg-id | CAMkU=1ya6Wx=2Aq3fn6TjxC6rvmUMPY55ffEXdRV27TMN7cEbg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: SEQUENCE values (duplicated) in some corner cases when crashhappens (Jeremy Schneider <schnjere@amazon.com>) |
| Ответы |
Re: SEQUENCE values (duplicated) in some corner cases when crash happens
|
| Список | 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 по дате отправления: