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

> > 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.)

Vadim