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

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Aleksander Alekseev <aleksander(at)timescale(dot)com>, 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>, 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 13:45:48
Message-ID: 6e24403a-0afb-f053-60b8-3b983266454c@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 28.03.22 12:46, Aleksander Alekseev wrote:
> 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.

At this point, I'm more concerned that code review is still finding
bugs, and that we have no test coverage for any of this, so we are
supposed to gain confidence in this patch by staring at it very hard. ;-)

AFAICT, this patch provides no actual functionality change, so holding
it a bit for early in the PG16 cycle wouldn't lose anything.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message James Coleman 2022-03-28 13:54:35 Re: Document atthasmissing default optimization avoids verification table scan
Previous Message Tom Lane 2022-03-28 13:35:31 Re: SQL/JSON: functions