Re: Sequence's value can be rollback after a crashed recovery.

From: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Sequence's value can be rollback after a crashed recovery.
Date: 2021-11-23 01:27:11
Message-ID: CAKU4AWoOstO3_7vfDDo73knFDj=qqZqH=+zLZXiWEt4QyNXQ6A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 23, 2021 at 4:31 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Bossart, Nathan" <bossartn(at)amazon(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message houzj.fnst@fujitsu.com 2021-11-23 01:58:05 RE: pg_get_publication_tables() output duplicate relid
Previous Message Andres Freund 2021-11-23 01:18:01 Re: Reduce function call costs on ELF platforms