From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Maxim Orlov <orlovmg(at)gmail(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Jacob Champion <jchampion(at)timescale(dot)com>, Japin Li <japinli(at)hotmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Subject: | Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15) |
Date: | 2023-02-27 09:10:38 |
Message-ID: | 3d298745-9183-c26e-3e12-0f6ebefc8e3e@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(CC list trimmed, gmail wouldn't let me send otherwise)
On 22/02/2023 16:29, Maxim Orlov wrote:
> On Tue, 21 Feb 2023 at 16:59, Aleksander Alekseev
> <aleksander(at)timescale(dot)com <mailto:aleksander(at)timescale(dot)com>> wrote:
> One thing that still bothers me is that during the upgrade we only
> migrate the CLOG segments (i.e. pg_xact / pg_clog) and completely
> ignore all the rest of SLRUs:
>
> * pg_commit_ts
> * pg_multixact/offsets
> * pg_multixact/members
> * pg_subtrans
> * pg_notify
> * pg_serial
>
> Hi! We do ignore these values, since in order to pg_upgrade the server
> it must be properly stopped and no transactions can outlast this moment.
That sounds right for pg_serial, pg_notify, and pg_subtrans. But not for
pg_commit_ts and the pg_multixacts.
This needs tests for pg_upgrading those SLRUs, after 0, 1 and N wraparounds.
I'm surprised that these patches extend the page numbering to 64 bits,
but never actually uses the high bits. The XID "epoch" is not used, and
pg_xact still wraps around and the segment names are still reused. I
thought we could stop doing that. Certainly if we start supporting
64-bit XIDs properly, that will need to change and we will pg_upgrade
will need to rename the segments again.
The previous versions of these patches did that, but I think you changed
tact in response to Robert's suggestion at [1]:
> Lest we miss the forest for the trees, there is an aspect of this
> patch that I find to be an extremely good idea and think we should try
> to get committed even if the rest of the patch set ends up in the
> rubbish bin. Specifically, there are a couple of patches in here that
> have to do with making SLRUs indexed by 64-bit integers rather than by
> 32-bit integers. We've had repeated bugs in the area of handling SLRU
> wraparound in the past, some of which have caused data loss. Just by
> chance, I ran across a situation just yesterday where an SLRU wrapped
> around on disk for reasons that I don't really understand yet and
> chaos ensued. Switching to an indexing system for SLRUs that does not
> ever wrap around would probably enable us to get rid of a whole bunch
> of crufty code, and would also likely improve the general reliability
> of the system in situations where wraparound is threatened. It seems
> like a really, really good idea.
These new versions of this patch don't achieve the goal of avoiding
wraparound. I think the previous versions that did that was the right
approach.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2023-02-27 09:26:19 | Re: Time delayed LR (WAS Re: logical replication restrictions) |
Previous Message | Amit Kapila | 2023-02-27 09:01:37 | Re: Allow logical replication to copy tables in binary format |