Re: lastOverflowedXid does not handle transaction ID wraparound - Mailing list pgsql-hackers

From Nikolay Samokhvalov
Subject Re: lastOverflowedXid does not handle transaction ID wraparound
Date
Msg-id CANNMO++1AVCvrrovcWdK-Dy9C5dq29twzjHSvTrBECAonQmzag@mail.gmail.com
Whole thread Raw
In response to Re: lastOverflowedXid does not handle transaction ID wraparound  (Stan Hu <stanhu@gmail.com>)
Responses Re: lastOverflowedXid does not handle transaction ID wraparound  (Nikolay Samokhvalov <samokhvalov@gmail.com>)
List pgsql-hackers
On Thu, Oct 21, 2021 at 07:21 Stan Hu <stanhu@gmail.com> wrote:
On Wed, Oct 20, 2021 at 9:01 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> lastOverflowedXid is the smallest subxid that possibly exists but
> possiblly not known to the standby. So if all top-level transactions
> older than lastOverflowedXid end, that means that all the
> subtransactions in doubt are known to have been ended.

Thanks for the patch! I verified that it appears to reset
lastOverflowedXid properly.

Is it right time to register the patch in the current commit fest, right? (How to do that?)

On a separate note, I think it would be really good to improve observability for SLRUs -- particularly for Subtrans SLRU and this overflow-related aspects.  pg_stat_slru added in PG13 is really helpful, but not enough to troubleshoot, analyze and tune issues like this, and the patches related to SLRU. Basic ideas:
- expose to the user how many pages are currently used (especially useful if SLRU sizes will be configurable, see
- Andrew Borodin also expressed the idea to extend pageinspect to allow seeing the content of SLRUs
- a more specific thing: allow seeing lastOverflowedXid somehow (via SQL or in logs) - we see how important it for standbys health, but we cannot see it now.

Any ideas in the direction of observability?

Nik

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Experimenting with hash tables inside pg_dump
Next
From: Soumyadeep Chakraborty
Date:
Subject: Re: Unnecessary delay in streaming replication due to replay lag