Horton

Re: Add 64-bit XIDs into PostgreSQL 15

Simon Riggs <simon.riggs@enterprisedb.com>

View thread
From: Simon Riggs <simon.riggs@enterprisedb.com>
To: Maxim Orlov <orlovmg@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Zhang Mingli <zmlpostgres@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, Dilip Kumar <dilipbalaut@gmail.com>, Pavel Borisov <pashkin.elfe@gmail.com>, Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers@lists.postgresql.org, Stephen Frost <sfrost@snowman.net>, Alexander Korotkov <aekorotkov@gmail.com>, Andres Freund <andres@anarazel.de>, Ilya Anfimov <ilan@tzirechnoy.com>
Date: 2022-11-24T17:42:31Z
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 Fri, 21 Oct 2022 at 17:09, Maxim Orlov <orlovmg@gmail.com> wrote:

> Reviews and opinions are very welcome!

I'm wondering whether the safest way to handle this is by creating a
new TAM called "heap64", so that all storage changes happens there.
(Obviously there are still many other changes in core, but they are
more easily fixed).

That would reduce the code churn around "heap", allowing us to keep it
stable while we move to the brave new world.

Many current users see stability as one of the greatest strengths of
Postgres, so while I very much support this move, I wonder if this
gives us a way to have both stability and innovation at the same time?

-- 
Simon Riggs                http://www.EnterpriseDB.com/