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.
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 |