Skip site navigation (1) Skip section navigation (2)

Re: Bug #613: Sequence values fall back to previously chec

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ben Grimm <bgrimm(at)zaeon(dot)com>
Cc: "Tom Pfau" <T(dot)Pfau(at)emCrit(dot)com>,"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>,"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bug #613: Sequence values fall back to previously chec
Date: 2002-03-14 23:58:04
Message-ID: 18248.1016150284@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Ben Grimm <bgrimm(at)zaeon(dot)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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-03-15 00:03:45
Subject: Re: [SQL] Syslog
Previous:From: Larry RosenmanDate: 2002-03-14 23:35:23
Subject: Re: [SQL] Syslog

pgsql-bugs by date

Next:From: Mikheev, VadimDate: 2002-03-15 00:17:39
Subject: Re: Bug #613: Sequence values fall back to previously chec
Previous:From: Ben GrimmDate: 2002-03-14 22:47:39
Subject: Re: Bug #613: Sequence values fall back to previously chec

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group