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: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, "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-24 00:30:37
Message-ID: CAKU4AWp39gxGw0=PErOpHNebPE+VWtgu4Uu18Jfz_KeJbfiH+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>
> You could say that that's the same rookie error as relying on the
> persistence of any other uncommitted DML ...
>

IIUC, This is not the same as uncommitted DML exactly. For any
uncommitted
DML, it is a rollback for sure. But as for sequence, The xmax is not
changed
during sequence's value update by design and we didn't maintain the multi
versions
for sequence, so sequence can't be rolled back clearly. The fact is a
dirty data page flush
can persist the change no matter the txn is committed or aborted. The
below example
can show the difference:

SELECT nextval('s'); -- 1
begin;
SELECT nextval('s'); \watch 0.1 for a while, many checkpointer or data
flush happened.
-- crashed.

If we run nextval('s') from the recovered system, we probably will _not_ get
the 2 (assume cachesize=1) like uncommitted DML.

--
Best Regards
Andy Fan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bossart, Nathan 2021-11-24 00:32:00 Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)
Previous Message Masahiko Sawada 2021-11-24 00:26:59 Re: Failed transaction statistics to measure the logical replication progress