Thread

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

   Vadim Mikheev <vmikheev@sectorbase.com> — 2002-03-13T21:03:44Z

   > 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
   
   

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

   Tom Lane <tgl@sss.pgh.pa.us> — 2002-03-13T22:00:56Z

   "Mikheev, Vadim" <vmikheev@SECTORBASE.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
   
   

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

   Tom Lane <tgl@sss.pgh.pa.us> — 2002-03-13T22:29:08Z

   I said:
   > 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.
   
   Oh, wait, I take that back: the checkpointer advances RedoRecPtr
   *before* it starts to dump disk buffers.
   
   I'm still worried about whether we shouldn't try to simplify, rather
   than add complexity.
   
   			regards, tom lane