Re: Add 64-bit XIDs into PostgreSQL 15

Hi,

On 2026-02-12 11:47:37 -0500, Robert Haas wrote:
> On Thu, Feb 12, 2026 at 1:17 AM Maxim Orlov <orlovmg@gmail.com> wrote:
> > Please make this clear for me. Do I understand correctly that you
> > oppose Postgres' ability to handle transactions more than an epoch
> > apart? For me, this is more than just an argument; it is the essence
> > of this patch.
> 
> Yes, I think I'm mostly against that.

+1

> I don't think there is much of a real use case for allowing the XID distance
> back to the oldest running transaction to exceed ~2 billion. Normally, long
> before a database gets to that point, the bloat has become so bad that the
> database has become unusable. There are exceptions, of course. If you have a
> workload where nearly all of the dead tuples are cleaned up by HOT-pruning,
> you might be able to survive this sort of scenario, but it's a pretty corner
> case, because most people are not going to have a workload where absolutely
> 100% of the updates are HOT.

I don't think HOT even helps you, since HOT cleanup typically will not be able
to clean up rows that are newer than the xmin horizon. There are some
exceptions, like rolled back insertions, but I don't think that is an
interesting scenario in the context of 2B transactions.

I think the only case that is somewhat kinda maybe realistically performing OK
is insert only workloads, where all that data is analyzed by very long running
queries.  But even there you prevent use of index only scans etc, so it's
really not something you want to do.


> As Heikki also says, the real benefit of doing something like this in
> my mind is to reduce the need for or the impact of aggressive
> vacuuming.

Indeed.


> If we are always able to determine a proper epoch for every tuple, no matter
> how old, then aggressive vacuums are only needed to keep the size of CLOG
> down, not to keep the database running. We can get that benefit without
> changing the in-memory tuple representation or the size of TransactionId,
> and, as Heikki said better than I can, that could make for a smaller patch
> with a better chance of actually going somewhere.

Right. And even if we had agreement on tackling the > 2B old running
transactions problem, I'd say that tackling it in one patch together with the
page level epoch is a good way to ensure the patch will not go anywhere.

Greetings,

Andres Freund