Re: Add 64-bit XIDs into PostgreSQL 15

From: adherent postgres <adherent_postgres(at)hotmail(dot)com>
To: Maxim Orlov <orlovmg(at)gmail(dot)com>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add 64-bit XIDs into PostgreSQL 15
Date: 2022-12-30 08:27:57
Message-ID: TY0PR0101MB4586FC91C59F4524D80C9E058EF09@TY0PR0101MB4586.apcprd01.prod.exchangelabs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Maxim Orlov:

>AFAICS, we have a following options:
>1. Making "true" 64Cbit XIDs. I.e. making every tuple have 64Cbit xmin and >xmax fields.
>2. Put special in every page where base for XIDs are stored. This is what we >have done in the current patch set.
>3. Put base for XIDs in a fork.
>4. Make explicit 64Cbit XIDs for concrete relations. I.e. CREATE TABLE foo >WITH (xid8) of smth.

I think the first solution will not be agreed by the core committers, they will consider that the change is too big and will affect the stability of PostgreSQL,I think the second solution is actually quite good, and you've been working on it now,and there are successful cases (opengauss is implemented in this way,In order to save space and be compatible with older versions, opengauss design is to store the xmin/xmax of the head of the tuple in two parts, the xmin/xmax of the head of the tuple is the number of uint32; the header of the page stores the 64-bit xid_base, which is the xid_base of the current page.),I think it's best to stick to this solution now.
Opengauss tuple structure:
[cid:3fae289c-7f88-46be-a775-2d93b1a9c41e]
Best wish

________________________________
发件人: Maxim Orlov <orlovmg(at)gmail(dot)com>
发送时间: 2022年12月28日 18:14
收件人: Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>
抄送: Robert Haas <robertmhaas(at)gmail(dot)com>; Chris Travers <chris(at)orioledata(dot)com>; Bruce Momjian <bruce(at)momjian(dot)us>; Aleksander Alekseev <aleksander(at)timescale(dot)com>; pgsql-hackers(at)lists(dot)postgresql(dot)org <pgsql-hackers(at)lists(dot)postgresql(dot)org>; Chris Travers <chris(dot)travers(at)gmail(dot)com>; Peter Geoghegan <pg(at)bowt(dot)ie>; Fedor Sigaev <teodor(at)sigaev(dot)ru>; Alexander Korotkov <aekorotkov(at)gmail(dot)com>; Konstantin Knizhnik <knizhnik(at)garret(dot)ru>; Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>; Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>; Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>
主题: Re: Add 64-bit XIDs into PostgreSQL 15

Hi!

I want to make a quick summary here.

1. An overall consensus has been reached: we shall focus on committing SLRU changes first.
2. I've created an appropriate patch set here [0].
3. How [0] is waiting for a review. As always, all opinions will be welcome.
4. While discussing error/warning messages and some other stuff, this thread was marked as "Waiting on Author".
5. I do rebase this patch set once in a week, but do not post it here, since there is no need in it. See (1).
6. For now, I don't understand what changes I have to make here. So, does "Waiting on Author" is appropriate status here?

Anyway. Let's discuss on-disk page format, shall we?

AFAICS, we have a following options:
1. Making "true" 64Cbit XIDs. I.e. making every tuple have 64Cbit xmin and xmax fields.
2. Put special in every page where base for XIDs are stored. This is what we have done in the current patch set.
3. Put base for XIDs in a fork.
4. Make explicit 64Cbit XIDs for concrete relations. I.e. CREATE TABLE foo WITH (xid8) of smth.

There were opinions that the proposed solution (2) is not the optimal. It would be great to hear your concerns and thoughts.

[0] https://www.postgresql.org/message-id/CACG%3Dezav34TL%2BfGXD5vJ48%3DQbQBL9BiwkOTWduu9yRqie-h%2BDg%40mail.gmail.com

--
Best regards,
Maxim Orlov.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-12-30 10:19:32 Re: appendBinaryStringInfo stuff
Previous Message Richard Guo 2022-12-30 08:05:55 Re: Removing redundant grouping columns