Re: [PoC] pg_upgrade: allow to upgrade publisher node
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Julien Rouhaud <rjuju123@gmail.com>, vignesh C <vignesh21@gmail.com>
Date: 2023-08-12T15:30:55Z
Lists: pgsql-hackers
On Sat, Aug 12, 2023 at 11:50:36AM +0530, Amit Kapila wrote: > > We will need that complexity somewhere, > > so why not in pg_upgrade? > > > > I don't think we need the complexity of version-specific checks if we > do what we do in get_control_data(). Basically, invoke > version-specific pg_replslotdata to get version-specific slot > information. There has been a proposal for a tool like that [1]. Do > you have something better in mind? If so, can you please explain the > same a bit more? Yes, if you want to break it out into a separate tool and then have pg_upgrade call/parse it like it calls/parses pg_controldata, that seems fine. > > > > After reading the control file and the slots' state files we > > > > check if slot's confirmed_flush_lsn matches the latest checkpoint LSN > > > > in the control file (BTW maybe we can get slot name and plugin name > > > > here instead of using pg_dump?). > > > > > > But isn't the advantage of doing via pg_dump (in binary_mode) that we > > > allow some outside core in-place upgrade tool to also use it if > > > required? If we don't think that would be required then we can > > > probably use the info we retrieve it in pg_upgrade. > > > > You mean the code reading the slot file? I don't see the point of > > adding user complexity to enable some hypothetical external usage. > > It is not just that we need a slot reading facility but rather mimic > something like pg_get_replication_slots() where we have to know the > walstate (WALAVAIL_REMOVED, etc.) as well. I am not against it but am > not sure that we do it for any other object in the upgrade. Can you > please point me out if we have any such prior usage? Even if we don't > do it today, we can start doing now if that makes sense but it appears > to me that we are accessing contents of data-dir/WAL by invoking some > other utilities like pg_controldata, pg_resetwal, so something similar > would make sense here. Actually, what we do here also somewhat depends > on what we decide for the other point we are discussing above in the > email. Yes, if there is value in having that information available via the command-line tool, it makes sense to add it. Let me add that developers have complained how pg_upgrade scrapes the output pg_controldata rather than reading the file, and we are basically do that some more with this. However, I think that is an appropriate approach. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Commits
-
Fix issues in binary_upgrade_logical_slot_has_caught_up().
- 0bf62460bb9e 17.0 landed
-
Fix a random failure in 003_logical_slots.pl.
- 63c5df126abb 17.0 landed
-
Fix a test in 003_logical_slots.
- 3e36e48d8efe 17.0 landed
-
Fix uninitialized slot array access during the upgrade.
- a7db71ed2787 17.0 landed
-
Fix the test 003_logical_slots.
- 8af917be6bad 17.0 landed
-
Commit b195e6d482 forgot to update meson.build.
- 8949b978ff49 17.0 landed
-
Use shorter file names in the upgrade logical slots test.
- b195e6d482b8 17.0 landed
-
Migrate logical slots to the new node during an upgrade.
- 29d0a77fa660 17.0 landed
-
Flush logical slots to disk during a shutdown checkpoint if required.
- e0b2eed047df 17.0 landed
-
Prevent possibility of panics during shutdown checkpoint.
- c6c333436491 10.0 cited