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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(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-11 01:45:38
Message-ID: ZNWSwvXLcSNHnL2D@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 10, 2023 at 10:37:04PM +0900, Masahiko Sawada wrote:
> On Thu, Aug 10, 2023 at 12:52 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > Are you suggesting doing this before we start the old cluster or after
> > we stop the old cluster? I was thinking about the pros and cons of
> > doing this check when the server is 'on' (along with other upgrade
> > checks something like the patch is doing now) versus when the server
> > is 'off'. I think the advantage of doing it when the server is 'off'
> > (after check_and_dump_old_cluster()) is that it will be ensured that
> > there is no extra WAL that could be generated during the upgrade and
> > has not been verified against confirmed_flush_lsn location. But OTOH,
> > to retrieve slot information when the server is 'off', we need a
> > separate utility or probably a functionality for the same in
> > pg_upgrade and also some WAL reading stuff which sounds to me like a
> > larger change that may not be warranted here. I think anyway the extra
> > WAL (if any got generated during the upgrade) won't be required after
> > the upgrade so not convinced to make such a check while the server is
> > 'off'. Are there reasons which make it better to do this while the old
> > cluster is 'off'?
>
> What I imagined is that we do this check before
> check_and_dump_old_cluster() while the server is 'off'. Reading the
> slot state file would be simple and I guess we would not need a tool
> or cli program for that.

Agreed.

> BTW this check would not be able to support live-check but I think
> it's not a problem as this check with a running server will never be
> able to pass.

Agreed.

--
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 Donghang Lin 2023-08-11 02:07:02 Re: 2023-08-10 release announcement draft
Previous Message Andres Freund 2023-08-11 00:44:12 Re: Add PG CI to older PG releases