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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, bgrimm(at)zaeon(dot)com,pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bug #613: Sequence values fall back to previously chec kpointed
Date: 2002-03-13 22:00:56
Message-ID: 11552.1016056856@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> writes:
> It seems safe to do NOT write WAL record if sequence
> LSN > system RedoRecPtr because of checkpoint started after our
> check would finish only after writing to disk sequence buffer with
> proper last_value and log_cnt (nextval keeps lock on sequence buffer).

Mmm ... maybe.  Is this safe if a checkpoint is currently in progress?
Seems like you could look at RedoRecPtr and decide you are okay, but you
really are not if checkpointer has already dumped sequence' disk
buffer and will later set RedoRecPtr to a value beyond the old LSN.
In that case you should have emitted a WAL record ... but you didn't.

Considering that we've found two separate bugs in this stuff in the past
week, I think that we ought to move in the direction of making it
simpler and more reliable, not even-more-complicated.  Is it really
worth all this trouble to avoid making a WAL record for each nextval()
call?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Ian BarwickDate: 2002-03-13 22:23:08
Subject: Re: Archives
Previous:From: Zeugswetter Andreas SB SDDate: 2002-03-13 21:39:49
Subject: Re: select max(column) not using index

pgsql-bugs by date

Next:From: Tom LaneDate: 2002-03-13 22:29:08
Subject: Re: Bug #613: Sequence values fall back to previously chec kpointed
Previous:From: Stephan SzaboDate: 2002-03-13 21:54:34
Subject: Re: referential constraint bug

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