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

  1. Fix issues in binary_upgrade_logical_slot_has_caught_up().

  2. Fix a random failure in 003_logical_slots.pl.

  3. Fix a test in 003_logical_slots.

  4. Fix uninitialized slot array access during the upgrade.

  5. Fix the test 003_logical_slots.

  6. Commit b195e6d482 forgot to update meson.build.

  7. Use shorter file names in the upgrade logical slots test.

  8. Migrate logical slots to the new node during an upgrade.

  9. Flush logical slots to disk during a shutdown checkpoint if required.

  10. Prevent possibility of panics during shutdown checkpoint.