Re: [PoC] pg_upgrade: allow to upgrade publisher node - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [PoC] pg_upgrade: allow to upgrade publisher node
Date
Msg-id ZNelr4bpZld07v5T@momjian.us
Whole thread Raw
In response to Re: [PoC] pg_upgrade: allow to upgrade publisher node  (Amit Kapila <amit.kapila16@gmail.com>)
List 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.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: logicalrep_worker_launch -- counting/checking the worker limits
Next
From: Andrew Dunstan
Date:
Subject: Re: run pgindent on a regular basis / scripted manner