Horton

Re: lastOverflowedXid does not handle transaction ID wraparound

Stan Hu <stanhu@gmail.com>

View thread View on postgr.es
From: Stan Hu <stanhu@gmail.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-10-20T15:55:12Z
Lists: pgsql-hackers 
On Wed, Oct 20, 2021 at 4:00 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote:

>
>
> > 17 окт. 2021 г., в 21:55, Dmitry Dolgov <9erthalion6@gmail.com>
> написал(а):
> > I wonder what would be side
> > effects of clearing it when the snapshot is not suboverfloved anymore?
>
> I think we should just invalidate lastOverflowedXid on every
> XLOG_RUNNING_XACTS if subxid_overflow == false. I can't find a reason not
> to do so.
>
>
On a replica, I think it's possible for lastOverflowedXid to be set even if
subxid_overflow is false on the primary and secondary (
https://github.com/postgres/postgres/blob/dc899146dbf0e1d23fb24155a5155826ddce34c9/src/backend/storage/ipc/procarray.c#L1327).
I thought subxid_overflow only gets set if there are more than
PGPROC_MAX_CACHED_SUBXIDS (64) used in a given transaction.

Should the replica be invalidating lastOverflowedXid if subxcnt goes to
zero in XLOG_RUNNING_XACTS? But if there's an outstanding snapshot with an
xmin that precedes lastOverflowedXid we might violate MVCC if we invalidate
this, so I wonder if we also need to check the snapshot with the lowest
xmin?

Commits

  1. Reset lastOverflowedXid on standby when needed

  2. Fix variable shadowing in procarray.c.

  3. Move InRecovery and standbyState global vars to xlogutils.c.