Re: Add 64-bit XIDs into PostgreSQL 15

From: Chris Travers <chris(dot)travers(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Fedor Sigaev <teodor(at)sigaev(dot)ru>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Aleksander Alekseev <afiskon(at)gmail(dot)com>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Maxim Orlov <orlovmg(at)gmail(dot)com>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>
Subject: Re: Add 64-bit XIDs into PostgreSQL 15
Date: 2022-11-21 07:58:00
Message-ID: 166901748004.1121.10903356503191507345.pgcf@coridan.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation: not tested

I have a very serious concern about the current patch set. as someone who has faced transaction id wraparound in the past.

I can start by saying I think it would be helpful (if the other issues are approached reasonably) to have 64-bit xids, but there is an important piece of context in reventing xid wraparounds that seems missing from this patch unless I missed something.

XID wraparound is a symptom, not an underlying problem. It usually occurs when autovacuum or other vacuum strategies have unexpected stalls and therefore fail to work as expected. Shifting to 64-bit XIDs dramatically changes the sorts of problems that these stalls are likely to pose to operational teams. -- you can find you are running out of storage rather than facing an imminent database shutdown. Worse, this patch delays the problem until some (possibly far later!) time, when vacuum will take far longer to finish, and options for resolving the problem are diminished. As a result I am concerned that merely changing xids from 32-bit to 64-bit will lead to a smaller number of far more serious outages.

What would make a big difference from my perspective would be to combine this with an inverse system for warning that there is a problem, allowing the administrator to throw warnings about xids since last vacuum, with a configurable threshold. We could have this at two billion by default as that would pose operational warnings not much later than we have now.

Otherwise I can imagine cases where instead of 30 hours to vacuum a table, it takes 300 hours on a database that is short on space. And I would not want to be facing such a situation.

The new status of this patch is: Waiting on Author

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2022-11-21 08:06:56 Re: [PoC] Improve dead tuple storage for lazy vacuum
Previous Message sirisha chamarthi 2022-11-21 07:52:59 Re: Fix comments atop pg_get_replication_slots