Re: [PoC] pg_upgrade: allow to upgrade publisher node

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>
Subject: Re: [PoC] pg_upgrade: allow to upgrade publisher node
Date: 2023-08-12 15:30:55
Message-ID: ZNelr4bpZld07v5T@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2023-08-12 15:57:25 Re: run pgindent on a regular basis / scripted manner
Previous Message Amit Kapila 2023-08-12 14:18:51 Re: logicalrep_worker_launch -- counting/checking the worker limits