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

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Maxim Orlov <orlovmg(at)gmail(dot)com>, Jacob Champion <jchampion(at)timescale(dot)com>, Japin Li <japinli(at)hotmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Peter Geoghegan <pg(at)bowt(dot)ie>, Michael Paquier <michael(at)paquier(dot)xyz>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Hamid Akhtar <hamid(dot)akhtar(at)percona(dot)com>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Ilya Anfimov <ilan(at)tzirechnoy(dot)com>
Subject: Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
Date: 2023-02-20 15:30:31
Message-ID: CAJ7c6TMLGHROYfj2kd6P8UvmzDWJSJ47fdYgTn8Ou9SE1oCryA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
v54-0001-Index-SLRUs-by-64-bit-integers-rather-than-by-32.patch application/octet-stream 60.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-02-20 15:30:43 Re: "out of relcache_callback_list slots" after multiple calls to pg_logical_slot_get_binary_changes
Previous Message Markur Sens 2023-02-20 15:25:23 pg_crc32c_armv8.c:35:9: error: implicit declaration of function '__crc32cb' is invalid in C99