Re: Sequence's value can be rollback after a crashed recovery.
Andy Fan <zhihui.fan1213@gmail.com>
From: Andy Fan <zhihui.fan1213@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Bossart, Nathan" <bossartn@amazon.com>,
Laurenz Albe <laurenz.albe@cybertec.at>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-11-23T01:27:11Z
Lists: pgsql-hackers
On Tue, Nov 23, 2021 at 4:31 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Bossart, Nathan" <bossartn@amazon.com> writes: > > I periodically hear rumblings about this behavior as well. At the > > very least, it certainly ought to be documented if it isn't yet. I > > wouldn't mind trying my hand at that. Perhaps we could also add a new > > configuration parameter if users really want to take the performance > > hit. > > A sequence's cache length is already configurable, no? > > We can hit this issue even cache=1. And even if we added the XLogFlush, with _cachesize=1_, the Xlog is still recorded/flushed every 32 values. I know your opinion about this at [1], IIUC you probably miss the SEQ_LOG_VALS design, it was designed for the performance reason to avoid frequent xlog updates already. But after that, the XLogSync is still not called which caused this issue. [1] https://www.postgresql.org/message-id/19521.1588183354%40sss.pgh.pa.us -- Best Regards Andy Fan
Commits
-
Doc: improve documentation about nextval()/setval().
- b0a7161c5640 11.15 landed
- 6d1bdd5e0712 14.2 landed
- 6365e3a0535f 12.10 landed
- 499552273d47 13.6 landed
- 09c11134916c 10.20 landed
- 4ac452e2285d 15.0 landed