Re: Add 64-bit XIDs into PostgreSQL 15

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Maxim Orlov <orlovmg(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Shubham Khanna <khannashubham1197(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, 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>, 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>
Subject: Re: Add 64-bit XIDs into PostgreSQL 15
Date: 2024-09-12 09:52:18
Message-ID: CAJ7c6TP9Ce021ebJ=5zOhMjiG3Wqg4hO6Mg0WsccErvAD9vZYA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael, Maxim,

> Apparently, the original thread will inevitably disintegrate into many separate ones.
> For me, looks like some kind of road map. One for 64-bit GUCs, another one to remove
> short file names from SLRUs and, to make things more complicated, [1] for cf entry [0],
> to get rid of MultiXactOffset wraparound by switching to 64 bits.
>
> [0] https://commitfest.postgresql.org/49/5205/
> [1] https://www.postgresql.org/message-id/flat/CACG%3DezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw%40mail.gmail.com

Agree.

To me it seems like we didn't reach a consensus regarding switching to
64-bit XIDs. Given that and the fact that the patchset is rather
difficult to rebase (and review) I suggest focusing on something we
reached a consensus for. I'm going to close a CF entry for this
particular thread as RwF unless anyone objects. We can always return
to this later, preferably knowing that there is a particular committer
who has time and energy for merging this.

--
Best regards,
Aleksander Alekseev

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2024-09-12 10:07:22 Re: Add has_large_object_privilege function
Previous Message Andrei Lepikhov 2024-09-12 09:51:19 Re: Incremental Sort Cost Estimation Instability