Re: Add 64-bit XIDs into PostgreSQL 15

On Thu, Jul 25, 2024 at 02:09:10PM +0300, Heikki Linnakangas wrote:
> On 25/07/2024 13:19, Peter Eisentraut wrote:
>> Conversely, if there is still some threshold (not disaster, but
>> efficiency or something else), would it still be useful to keep these
>> settings well below 2^31?  In which case, we might not need 64-bit GUCs.
>
> Yeah, I don't think it's critical. It makes sense to switch to 64 bit GUCs,
> so that you can make those settings higher, but it's not critical or
> strictly required for the rest of the work.

It looks like we have some sort of consensus to introduce these GUC
APIs, then? I'd suggest to split that into its own thread because it
can be treated as an independent subject. (I know that this was
discussed previously, but it's been some time and this is going to
require a rebased version anyway, so..)

> Another approach is to make the GUCs to mean "thousands of XIDs", similar to
> how many of our memory settings are in kB rather than bytes. that might be a
> super confusing change for existing settings though.

I find that a bit confusing as well, still that would be OK in terms
of compatibility as long as you enforce the presence of a unit and
leave the default behavior alone. So it does not sound that bad to
be, either. It is also a bit simpler to set for users. Less zeros to
deal with.

Aleksander Alekseev has proposed to remove short file names from SLRUs
to cimplify its internals, as of this thread, so that's one less topic
to deal with here:
https://www.postgresql.org/message-id/CAJ7c6TOy7fUW9MuNeOWor3cSFnQg9tgz%3DmjXHDb94GORtM_Eyg%40mail.gmail.com

I am unclear about the rest of the thread. Considering v55-0004 and
v55-0003 as two different topics, what should we do with the other
things? It does not seem to me that we have a clear consensus on if
we are going to do something about some epoch:xid -> 64b XID switch,
and what are the arguments in play here. The thread has been long, so
I may be just missing the details but a summary would be nice.
--
Michael