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
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 |