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: Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Maxim Orlov <orlovmg(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Japin Li <japinli(at)hotmail(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: 2022-03-28 10:46:02
Message-ID: CAJ7c6TO9+_G6MXsRxoxC2Luo65M3Tp+A860QCvhO6_d-6OBKYQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers,

> Here is v30.

I took another look at the patchset. Personally I don't think it will get much
better than it is now. I'm inclined to change the status of the CF entry to
"Ready for Committer" unless anyone disagrees.

cfbot reports a problem with t/013_partition.pl but the test seems to be flaky
on `master` [1]. I couldn't find anything useful in the logs except for
"[postmaster] LOG: received immediate shutdown request". Then I re-checked the
patchset on FreeBSD 13 locally. The patchset passed `make installcked-world`.

> About v25-0002-Use-64-bit-format-to-output-XIDs.patch:
> I don't see the point of applying this now. It doesn't make PG15 any
> better. It's just a patch part of which we might need later.

> It was proposed in [1] that we'd better cut it into separate threads and
> commit by parts, some into v15, the other into v16. So we did. In view of
> this, I can not accept that 0002 patch doesn't make v15 better. I consider
> it is separate enough to be committed as a base to further 64xid parts.

I understand how disappointing this may be.

Personally I don't have a strong opinion here. Merging the patch sooner will
allow us to move toward 64-bit XIDs faster (e.g. to gather the feedback from
the early adopters, allow the translators to do their thing earlier, etc).
Merging it later will make PG15 more stable (you can't break anything new if
you don't change anything). As always, engineering is all about compromises.

It's up to the committer to decide.

[1]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=frogfish&dt=2022-03-25%2018%3A37%3A10

--
Best regards,
Aleksander Alekseev

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-03-28 11:00:33 Re: support for MERGE
Previous Message Jian Guo 2022-03-28 09:55:39 Re: Summary Sort workers Stats in EXPLAIN ANALYZE