Re: Bug #613: Sequence values fall back to previously chec - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Bug #613: Sequence values fall back to previously chec
Date
Msg-id 18248.1016150284@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug #613: Sequence values fall back to previously chec  (Ben Grimm <bgrimm@zaeon.com>)
List pgsql-bugs
Ben Grimm <bgrimm@zaeon.com> writes:
> The behavior of SELECT nextval() should not be conditional on being in or 
> out of a transaction block.

Nonsense.  The behavior of INSERT or UPDATE is "conditional" in exactly
the same way: you should not rely on the reported result until it's
committed.

Given Vadim's performance concerns, I doubt he'll hold still for forcing
an XLogFlush immediately every time a sequence XLOG record is written
-- but AFAICS that'd be the only way to guarantee durability of a
nextval result in advance of commit.  Since I don't think that's an
appropriate goal for the system to have, I don't care for it either.

I'm planning to try coding up Vadim's approach (pay attention to page's
old LSN to see if a WAL record must be generated) tonight or tomorrow
and see if it seems reasonable.
        regards, tom lane


pgsql-bugs by date:

Previous
From: Ben Grimm
Date:
Subject: Re: Bug #613: Sequence values fall back to previously chec
Next
From: 'Ben Grimm'
Date:
Subject: Re: Bug #613: Sequence values fall back to previously chec