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: "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>,"Tom Pfau" <T(dot)Pfau(at)emCrit(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-15 14:39:04
Message-ID: 20915.1016203144@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Attached is a patch against current CVS that fixes both of the known
problems with sequences: failure to flush XLOG after a transaction
that only does "SELECT nextval()", and failure to force a new WAL
record to be written on the first nextval after a checkpoint.
(The latter uses Vadim's idea of looking at the sequence page LSN.)
I haven't tested it really extensively, but it seems to cure the
reported problems.

Some notes:

1. I found what I believe is another bug in the sequence logic:
		fetch = log = fetch - log + SEQ_LOG_VALS;
should be
		fetch = log = fetch + SEQ_LOG_VALS;
I can't see any reason to reduce the number of values prefetched
by the number formerly prefetched.  Also, if the sequence's "cache"
setting is large (more than SEQ_LOG_VALS), the original code could
easily fail to fetch as many values as it was supposed to cache,
let alone additional ones to be prefetched and logged.

2. I renamed XLogCtl->RedoRecPtr to SavedRedoRecPtr, and renamed
the associated routines to SetSavedRedoRecPtr/GetSavedRedoRecPtr,
in hopes of reducing confusion.

3. I believe it'd now be possible to remove SavedRedoRecPtr and
SetSavedRedoRecPtr/GetSavedRedoRecPtr entirely, in favor of letting
the postmaster fetch the updated pointer with GetRedoRecPtr just
like a backend would.  This would be cleaner and less code ... but
someone might object that it introduces a risk of postmaster hangup,
if some backend crashes whilst holding info_lck.  I consider that
risk minuscule given the short intervals in which info_lck is held,
but it can't be denied that the risk is not zero.  Thoughts?

Comments?  Unless I hear objections I will patch this in current
and the 7.2 branch.  (If we agree to remove SavedRedoRecPtr,
though, I don't think we should back-patch that change.)

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-03-15 15:11:35
Subject: Re: User Level Lock question
Previous:From: Tom LaneDate: 2002-03-15 14:34:36
Subject: Re: Bug #613: Sequence values fall back to previously chec

pgsql-bugs by date

Next:From: Bruce MomjianDate: 2002-03-15 15:43:25
Subject: Re: [HACKERS] Bug #613: Sequence values fall back to previously
Previous:From: Tom LaneDate: 2002-03-15 14:34:36
Subject: Re: Bug #613: Sequence values fall back to previously chec

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