Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15) - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
Date
Msg-id CAJ7c6TMLGHROYfj2kd6P8UvmzDWJSJ47fdYgTn8Ou9SE1oCryA@mail.gmail.com
Whole thread Raw
In response to Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)  (Aleksander Alekseev <aleksander@timescale.com>)
Responses Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers
Hi,

> OK, here is the patchset v53 where I mostly modified the commit
> messages. It is explicitly said that 0001 modifies the WAL records and
> why we decided to do it in this patch. Additionally any mention of
> 64-bit XIDs is removed since it is not guaranteed that the rest of the
> patches are going to be accepted. 64-bit SLRU page numbering is a
> valuable change per se.
>
> Changing the status of the CF entry to RfC apparently was a bit
> premature. It looks like the patchset can use a few more rounds of
> review.
>
> In 0002:
>
> [...]
>
> Maxim, perhaps you could share with us what your reasoning was here?

I played with the patch a bit and managed to figure out what you tried
to accomplish. Unfortunately generally you can't derive a
FullTransactionId from a TransactionId, and you can't access
ShmemVariableCache fields without taking a lock unless during the
startup when there are no concurrent processes.

I don't think this patch should do anything but change the SLRU
indexing from 32-bit to 64-bit one. Trying to address the wraparounds
would be nice but I'm afraid we are not quite there yet.

Also I found strage little changes that seemed to be unrelated to the
patch. I believe they ended up here by accident (used to be a part of
64-bit XIDs patchset) and removed them.

PFA the cleaned up version of the patch. I noticed that splitting it
into parts doesn't help much with the review or testing, nor seems it
likely that the patches are going to be merged separately one by one.
For these reasons I merged everything into a single patch.

The convert_pg_xact_segments() function is still obviously
overengineered. As I understand, all it has to do is simply renaming
pg_xact/XXXX to pg_xact/00000000XXXX. Unfortunately I used up all the
mana for today and have to take a long rest in order to continue.

-- 
Best regards,
Aleksander Alekseev

Attachment

pgsql-hackers by date:

Previous
From: Markur Sens
Date:
Subject: pg_crc32c_armv8.c:35:9: error: implicit declaration of function '__crc32cb' is invalid in C99
Next
From: Tom Lane
Date:
Subject: Re: "out of relcache_callback_list slots" after multiple calls to pg_logical_slot_get_binary_changes