Re: Sequence's value can be rollback after a crashed recovery. - Mailing list pgsql-hackers

From Andy Fan
Subject Re: Sequence's value can be rollback after a crashed recovery.
Date
Msg-id CAKU4AWoqswkRc89LLXFtw9n2dMPTBB5KEsoRn4wTTAF5wRvLRw@mail.gmail.com
Whole thread Raw
In response to Re: Sequence's value can be rollback after a crashed recovery.  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: Sequence's value can be rollback after a crashed recovery.
List pgsql-hackers

> 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 

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: logical decoding and replication of sequences
Next
From: Amul Sul
Date:
Subject: Re: [Patch] ALTER SYSTEM READ ONLY