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
