Re: Add 64-bit XIDs into PostgreSQL 15

On Mon, Nov 21, 2022 at 12:25 PM Aleksander Alekseev <
aleksander(at)timescale(dot)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
>
>
>