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  (Jeremy Schneider <schnjere@amazon.com>)
Список 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 по дате отправления:

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Re: new heapcheck contrib module
Следующее
От: Jeremy Schneider
Дата:
Сообщение: Re: SEQUENCE values (duplicated) in some corner cases when crash happens