> > 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.
CheckPointer updates system RedoRecPtr before doing anything else.
System RedoRecPtr was introduced to force data buffers backup
by future XLogInsert-s once CheckPointer started and it *must* be
updated *before* buffer flushing.
> 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.
Isn't it too late, considering we have fixes for both bugs already? -:)
(And it's not very-more-complicated - just simple check.)
> Is it really worth all this trouble to avoid making a WAL record
> for each nextval() call?
It's doable... why not do this?
(Though I have no strong objection.)
pgsql-hackers by date
|Next:||From: mlw||Date: 2002-03-13 23:01:12|
|Subject: Re: Transaction on start of session ?|
|Previous:||From: Tom Lane||Date: 2002-03-13 22:29:08|
|Subject: Re: Bug #613: Sequence values fall back to previously chec kpointed |
pgsql-bugs by date
|Next:||From: Peter Eisentraut||Date: 2002-03-13 23:06:16|
|Subject: Re: Case sensitive table names ?|
|Previous:||From: Ben Grimm||Date: 2002-03-13 22:32:28|
|Subject: Re: Bug #613: Sequence values fall back to previously checkpointed|