Horton

Re: lastOverflowedXid does not handle transaction ID wraparound

Dmitry Dolgov <9erthalion6@gmail.com>

View thread View on postgr.es
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Stan Hu <stanhu@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2021-10-17T16:55:21Z
Lists: pgsql-hackers 
> On Tue, Oct 12, 2021 at 09:53:22PM -0700, Stan Hu wrote:
>
> I described how PostgreSQL can enter into a suboverflow condition on
> the replica under a number of conditions:
>
> 1. A long transaction starts.
> 2. A single SAVEPOINT is issued.
> 3. Many rows are updated on the primary, and the same rows are read
> from the replica.
>
> I noticed that lastOverflowedXid doesn't get cleared even after all
> subtransactions have been completed. On a replica, it only seems to be
> updated via a XLOG_XACT_ASSIGNMENT, but no such message will be sent
> if subtransactions halt. If the XID wraps around again and a long
> transaction starts before lastOverflowedXid, the replica might
> unnecessarily enter in the suboverflow condition again.

Hi,

that's an interesting finding, thanks for the investigation. I didn't
reproduce it fully (haven't checked the wraparound part), but indeed
lastOverflowedXid is not changing that often, only every
PGPROC_MAX_CACHED_SUBXIDS subtransactions. I wonder what would be side
effects of clearing it when the snapshot is not suboverfloved anymore?

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.