Re: SIGQUIT and lost sequence WAL records

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: SIGQUIT and lost sequence WAL records
Date: 2016-02-17 14:54:30
Message-ID: 15747.1455720870@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Michael Paquier <michael(dot)paquier(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message iurii.i.popov 2016-02-17 15:03:02 BUG #13966: Documentation. 'Select' description
Previous Message Michael Paquier 2016-02-17 13:55:16 SIGQUIT and lost sequence WAL records