Horton

Re: Add 64-bit XIDs into PostgreSQL 15

Ilya Anfimov <ilan@tzirechnoy.com>

View thread
From: Ilya Anfimov <ilan@tzirechnoy.com>
To: pgsql-hackers@lists.postgresql.org, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-01-17T06:46:55Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add SLRU tests for 64-bit page case

  2. Make use FullTransactionId in 2PC filenames

  3. Use larger segment file names for pg_notify

  4. Index SLRUs by 64-bit integers rather than by 32-bit integers

On Wed, Jan 05, 2022 at 06:51:37PM -0500, Bruce Momjian wrote:
> On Tue, Jan 4, 2022 at 10:22:50PM +0000, Finnerty, Jim wrote:

[skipped]

> > with the "double-xmax" representation.  This would eliminate a whole
> > class of coding errors and would make the code dealing with 64-bit
> > XIDs simpler and more maintainable.
> 
> Well, yes, we could do this, and it would avoid the complexity of having
> to support two XID representations, but we would need to accept that
> fast pg_upgrade would be impossible in such cases, since every page
> would need to be checked and potentially updated.
> 
> You might try to do this while the server is first started and running
> queries, but I think we found out from the online checkpoint patch that
> having the server in an intermediate state while running queries is very
> complex --- it might be simpler to just accept two XID formats all the
> time than enabling the server to run with two formats for a short
> period.  My big point is that this needs more thought.

 Probably, some table storage housekeeping would be wanted.

 Like  a column in pg_class describing the current set of options
of the table: checksums added, 64-bit xids added, type of  64-bit
xids  (probably  some would want to add support for the pgpro up-
grades), some set of defaults to not include a lot of them in all
pageheaders  --  like  compressed xid/integer formats or extended
pagesize.

 And  separate tables  that  describe  the  transition  state  --
like  when  adding  checksums, the desired state for the relation
(checksums), and a set of ranges in the table files that are  al-
ready transitioned/checked.

 That  probably  will not introduce too much slowdown at least on
reading, and will add the transition/upgrade mechanics.


 Aren't there were already some discussions about such a  feature
in the mailing lists?

> 
> 
> -- 
>   Bruce Momjian  <bruce@momjian.us>        https://momjian.us
>   EDB                                      https://enterprisedb.com
> 
>   If only the physical world exists, free will is an illusion.
> 
>