Re: Add 64-bit XIDs into PostgreSQL 15 - Mailing list pgsql-hackers

From Chris Travers
Subject Re: Add 64-bit XIDs into PostgreSQL 15
Date
Msg-id CAEq-hvsHa=KNs8Rkh_s5j5dwZs7BHb=AJJm+0JCVWd+USYOQpA@mail.gmail.com
Whole thread Raw
In response to Re: Add 64-bit XIDs into PostgreSQL 15  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers


On Mon, Nov 21, 2022 at 12:25 PM Aleksander Alekseev <aleksander@timescale.com> wrote:
Hi hackers,

> > I have a very serious concern about the current patch set. as someone who has faced transaction id wraparound in the past.
>
> [...]
>
> I had a similar stance when I started working on this patch. Of
> course, it seemed horrible just to postpone the consequences of
> inadequate monitoring, too long running transactions that prevent
> aggressive autovacuum etc. So I can understand your point.
>
> With time I've got to a little bit of another view of this feature i.e.
>
> 1. It's important to correctly set monitoring, the cut-off of long
> transactions, etc. anyway. It's not the responsibility of vacuum
> before wraparound to report inadequate monitoring etc. Furthermore, in
> real life, this will be already too late if it prevents 32-bit
> wraparound and invokes much downtime in an unexpected moment of time
> if it occurs already. (The rough analogy for that is the machine
> running at 120mph turns every control off and applies full brakes just
> because the cooling liquid is low (of course there might be a warning
> previously, but anyway))
>
> 2. The checks and handlers for the event that is never expected in the
> cluster lifetime (~200 years at constant rate of 1e6 TPS) can be just
> dropped. Of course we still need to do automatic routine maintenance
> like cutting SLRU buffers (but with a much bigger interval if we have
> much disk space e.g.). But I considered that we either can not care
> what will be with cluster after > 200 years (it will be migrated many
> times before this, on many reasons not related to Postgres even for
> the most conservative owners). So the radical proposal is to drop
> 64-bit wraparound at all. The most moderate one is just not taking
> very much care that after 200 years we have more hassle than next
> month if we haven't set up everything correctly. Next month's pain
> will be more significant even if it teaches dba something.
>
> Big thanks for your view on the general implementation of this feature, anyway.

I'm inclined to agree with Pavel on this one. Keeping 32-bit XIDs in
order to intentionally trigger XID wraparound to indicate the ending
disk space and/or misconfigured system (by the time when it's usually
too late anyway) is a somewhat arguable perspective. It would be great
to notify the user about the potential issues with the configuration
and/or the fact that VACUUM doesn't catch up. But it doesn't mean we
should keep 32-bit XIDs in order to achive this.

That's not what I am suggesting.  However I am saying that removing a symptom of a problem so you get bit when you are in an even worse position is a bad idea, and I would strenuously oppose including a patchset like this without some sort of mitigating measures.

What I think should be added to address this concern is a GUC variable of warn_max_xid_lag, and then change the logic which warns of impending xid wraparound to logic that warns of xid lag reaching a value in excess of this threshold.

Databases under load take a long time to correct problems and throwing new problems onto DBA-land and saying "you figure out your monitoring" is not something I want to support.  Again, this comes from experience facing xid wraparound issues.  I have nothing against 64-bit xids.  But I think the patch ought not to delay onset of visible symptoms, that instead the focus should be on making sure that efforts to address those symptoms can be handled using less extreme measures and at a bit of a more relaxed pace.
 

--
Best regards,
Aleksander Alekseev


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: wake up logical workers after ALTER SUBSCRIPTION
Next
From: Chris Travers
Date:
Subject: Re: Add 64-bit XIDs into PostgreSQL 15