From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
Cc: | 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-22 13:09:52 |
Message-ID: | ce9717a49965a1490c0d442e8b885bb4fbbd4664.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2021-11-22 at 15:43 +0800, Andy Fan wrote:
> > > The reason is because we never flush the xlog for the nextval_internal
> > > for the above case. So if
> > > the system crashes, there is nothing to redo from. It can be fixed
> > > with the following online change
> > > code.
> > >
> > > @@ -810,6 +810,8 @@ nextval_internal(Oid relid, bool check_permissions)
> > > recptr = XLogInsert(RM_SEQ_ID, XLOG_SEQ_LOG);
> > >
> > > PageSetLSN(page, recptr);
> > > +
> > > + XLogFlush(recptr);
> > > }
> > >
> > >
> > > If a user uses sequence value for some external systems, the
> > > rollbacked value may surprise them.
> > > [I didn't run into this issue in any real case, I just studied xlog /
> > > sequence stuff today and found this case].
> >
> > I think that is a bad idea.
> > It will have an intolerable performance impact on OLTP queries, doubling
> > the number of I/O requests for many cases.
>
> The performance argument was expected before this writing. If we look at the
> nextval_interval more carefully, we can find it would not flush the xlog every
> time even the sequence's cachesize is 1. Currently It happens every 32 times
> on the nextval_internal at the worst case.
Right, I didn't think of that. Still, I'm -1 on this performance regression.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | David Christensen | 2021-11-22 13:47:41 | Re: CREATE ROLE IF NOT EXISTS |
Previous Message | Robert Haas | 2021-11-22 12:59:20 | Re: Begin a transaction on a SAVEPOINT that is outside any transaction |