Re: Add 64-bit XIDs into PostgreSQL 15

Hi,

On 2026-02-07 20:30:41 -0500, Robert Haas wrote:
> On Sat, Feb 7, 2026 at 5:47 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > The thing I like least about this is how the upgrade works, i.e. the
> > conversion code and the "double xmax" hack. This would look much nicer
> > if we could start from clean slate and just add the fields we need to
> > the page header. However, upgrade is important, that point has been
> > discussed a lot on the list, and I don't have any better ideas. I think
> > it's as good as it gets at the high level.
> 
> I don't think the page header is the right thing, because that applies
> to every AM, including both table AMs and index AMs. I'd say that some
> of the things we already have in the page header don't really make
> sense there -- in particular, pd_prune_xid, which is heap-specific. We
> can't change that at this point, but we shouldn't make it worse.

On the topic of pd_prune_xid - I've been wondering if, instead of the double
xmax approach, the high bits of the 64bit xid could be stored in pd_prune_xid,
signified by a flag on the page indicating so.



WRT heap specific stuff in non-heap code: I think the way that the patch
integrates the format conversion into bufmgr's IO path is pretty much
unacceptable (the call to convert_page() is in
buffer_readv_complete_one()). Completely obviously the bufmgr layer has no
business doing so, and there's absolutely no guarantee that a relkind =
r/t/... page is a heap page.

The patch also adds a pointer to the open relation to IO handles, to be able
to know what relkind a buffer being read into is. But that's nonsensical, the
backend actually executes the completion handler might not be the backend that
issued the IO, which means that that pointer can be completely bogus.  Also
the relation might be closed by that point (think of a query that errors out
after starting IO).  If this patch passes tests, I'm rather baffled.


I strongly agree with the points made upthread about not changing
TransactionId to 64bit, we already have a 64bit representation - what's the
point of having two and introducing a new ShortTransactionId type?


Greetings,

Andres Freund