Re: SIGQUIT and lost sequence WAL records
От | Tom Lane |
---|---|
Тема | Re: SIGQUIT and lost sequence WAL records |
Дата | |
Msg-id | 15747.1455720870@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | SIGQUIT and lost sequence WAL records (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: SIGQUIT and lost sequence WAL records
|
Список | pgsql-bugs |
Michael Paquier <michael.paquier@gmail.com> writes: > Lately a couple of colleagues have pinged me regarding the fact that a > server signaled with SIGQUIT, or "pg_ctl stop -m immediate", may > ignore sequence WAL records. I've not gone through this in detail, but I think what is happening is that since the test case never commits any transactions, the sequence-advance WAL records may not get flushed to disk, and thus of course are not available for replay. This is not a bug IMO, as by the exact same token, no uses of those nextval() values can appear in any committed tuples, so no database inconsistency is possible. If an application is using nextval() results *externally to the database*, it's unsafe for it to rely on those values being unique unless/until it commits the nextval() calls. I seem to recall some past discussions about whether a transaction that commits after writing only a sequence advance (that is, it did nextval() and nothing else) needs to flush WAL. I think at one point it did not but we changed it because of this consideration. [ digs around... ] That was a long time ago: see 01747692f. regards, tom lane
В списке pgsql-bugs по дате отправления: