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

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

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: bgrimm(at)zaeon(dot)com, pgsql-bugs(at)postgresql(dot)org,"'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug #613: Sequence values fall back to previously chec
Date: 2002-03-13 21:03:44
Message-ID: 3705826352029646A3E91C53F7189E325184D4@sectorbase2.sectorbase.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
> AFAICS the only way that we could make the one-WAL-record-every-32-
> nextvals idea really work would be if CHECKPOINT could nullify the
> logged-in-advance state of each sequence (so that the first nextval
> after a checkpoint would always generate a fresh WAL record, but
> subsequent ones wouldn't have to).  But I don't see any practical
> way for CHECKPOINT to do that, especially not for sequences whose
> disk block isn't even in memory at the instant of the CHECKPOINT.

But sequences can force WAL record if sequence page LSN is <= than
system RedoRecPtr (XLogCtlInsert.RedoRecPtr), ie previously made
sequence WAL record is "too old" and would not be played during
restart. 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).

What is not good is that to read system RedoRecPtr backend has to
acquire XLogInsertLock but probably we can change system RedoRecPtr
read/write rules:

- to update RedoRecPtr one has to keep not only XLogInsertLock
  but also acquire XLogInfoLock (this is only CheckPointer who
  updates RedoRecPtr);
- to read RedoRecPtr one has to keep either XLogInsertLock or
  XLogInfoLock.

This way nextval would only acquire XLogInfoLock to check
system RedoRecPtr.

?

Vadim

Responses

pgsql-hackers by date

Next:From: Ian BarwickDate: 2002-03-13 21:12:40
Subject: Re: psql and output from \?
Previous:From: Bruce MomjianDate: 2002-03-13 20:46:27
Subject: Re: Archives

pgsql-bugs by date

Next:From: Stephan SzaboDate: 2002-03-13 21:54:34
Subject: Re: referential constraint bug
Previous:From: Bruce MomjianDate: 2002-03-13 20:31:25
Subject: Re: referential constraint bug

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