Re: lastOverflowedXid does not handle transaction ID wraparound

Поиск
Список
Период
Сортировка
От Nikolay Samokhvalov
Тема Re: lastOverflowedXid does not handle transaction ID wraparound
Дата
Msg-id CANNMO++1AVCvrrovcWdK-Dy9C5dq29twzjHSvTrBECAonQmzag@mail.gmail.com
обсуждение исходный текст
Ответ на Re: lastOverflowedXid does not handle transaction ID wraparound  (Stan Hu <stanhu@gmail.com>)
Ответы Re: lastOverflowedXid does not handle transaction ID wraparound  (Nikolay Samokhvalov <samokhvalov@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Experimenting with hash tables inside pg_dump
Следующее
От: Soumyadeep Chakraborty
Дата:
Сообщение: Re: Unnecessary delay in streaming replication due to replay lag