From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Jeremy Schneider <schnjere(at)amazon(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Vinicius Abrahao <vinnix(dot)bsd(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Vinícius Schmidt <vinics(at)amazon(dot)com> |
Subject: | Re: SEQUENCE values (duplicated) in some corner cases when crash happens |
Date: | 2020-05-14 21:58:35 |
Message-ID: | CAMkU=1ya6Wx=2Aq3fn6TjxC6rvmUMPY55ffEXdRV27TMN7cEbg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 6, 2020 at 1:52 PM Jeremy Schneider <schnjere(at)amazon(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Schneider | 2020-05-14 22:09:28 | Re: SEQUENCE values (duplicated) in some corner cases when crash happens |
Previous Message | Mark Dilger | 2020-05-14 21:53:53 | Re: new heapcheck contrib module |