Re: Sequence's value can be rollback after a crashed recovery.
| От | Andy Fan |
|---|---|
| Тема | Re: Sequence's value can be rollback after a crashed recovery. |
| Дата | |
| Msg-id | CAKU4AWoqswkRc89LLXFtw9n2dMPTBB5KEsoRn4wTTAF5wRvLRw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Sequence's value can be rollback after a crashed recovery. (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
| Ответы |
Re: Sequence's value can be rollback after a crashed recovery.
|
| Список | pgsql-hackers |
> I think at this thread[1], which claimed to get this issue even after
> commit, I haven't tried it myself though.
>
> [1] https://www.postgresql.org/message-id/flat/ea6485e3-98d0-24a7-094c-87f9d5f9b18f%40amazon.com#4cfe7217c829419b769339465e8c2915
>
I did try, and I haven't been able to reproduce that behavior (on
master, at least).
I agree with this, the commit would flush the xlog and persist the change.
I see Tom speculated we may not flush WAL if a transaction only does
nextval() in that other thread, but I don't think that's true. AFAICS if
the nextval() call writes stuff to WAL, the RecordTransactionCommit will
have wrote_xlog=true and valid XID. And so it'll do the usual usual
XLogFlush() etc.
I agree with this as well. or else, how can we replicate it to standby if
user only runs the SELECT nextval('s') in a transaction.
> I fail to see how that's less durable than any other DML (e.g. we don't
> complain about INSERT not being durable if you don't commit the change).
> If you can show that the sequence goes back after a commit, that'd be an
actual durability issue.
> If you can show that the sequence goes back after a commit, that'd be an
actual durability issue.
This can't be called a tranaction's durability issue, but people usually think
the value of sequence will not rollback. so it may surprise people if that happens.
Best Regards
Andy Fan
В списке pgsql-hackers по дате отправления: