>
>
> > I think at this thread[1], which claimed to get this issue even after
> > commit, I haven't tried it myself though.
> >
> > [1]
> https://www.postgresql.org/message-id/flat/ea6485e3-98d0-24a7-094c-87f9d5f9b18f%40amazon.com#4cfe7217c829419b769339465e8c2915
> >
>
> I did try, and I haven't been able to reproduce that behavior (on
> master, at least).
>
>
I agree with this, the commit would flush the xlog and persist the change.
> I see Tom speculated we may not flush WAL if a transaction only does
> nextval() in that other thread, but I don't think that's true. AFAICS if
> the nextval() call writes stuff to WAL, the RecordTransactionCommit will
> have wrote_xlog=true and valid XID. And so it'll do the usual usual
> XLogFlush() etc.
>
>
I agree with this as well. or else, how can we replicate it to standby if
user only runs the SELECT nextval('s') in a transaction.
> I fail to see how that's less durable than any other DML (e.g. we don't
> complain about INSERT not being durable if you don't commit the change).
> If you can show that the sequence goes back after a commit, that'd be an
actual durability issue.
This can't be called a tranaction's durability issue, but people usually
think
the value of sequence will not rollback. so it may surprise people if that
happens.
--
Best Regards
Andy Fan
