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.
