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-11 18:08:39
Message-ID: ZNZ5J4+kM1y1e2RL@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 11, 2023 at 10:46:31AM +0530, Amit Kapila wrote:
> On Thu, Aug 10, 2023 at 7:07 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > 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. We need to expose RepliactionSlotOnDisk,
> > though.
>
> Won't that require a lot of version-specific checks as across versions
> the file format could be different? For the case of the control file,
> we use version-specific pg_controldata (for the old cluster, the
> corresponding version's pg_controldata) utility to read the old
> version control file. I thought we need something similar here if we
> want to do what you are suggesting.

You mean the slot file format? We will need that complexity somewhere,
so why not in pg_upgrade?

> > 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.

> > the first commit. Or another idea would be to allow users to mark
> > replication slots "upgradable" so that pg_upgrade skips the
> > confirmed_flush_lsn check.
>
> I guess for that we need to ask users to ensure that confirm_flush_lsn
> is up-to-date and then provide some slot-level API to mark the slots
> with the required status. If so, that sounds a bit complicated for
> users.

Agreed, not worth it.

--
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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-08-11 18:09:37 Re: LLVM 16 (opaque pointers)
Previous Message Bruce Momjian 2023-08-11 18:03:47 Re: [PoC] pg_upgrade: allow to upgrade publisher node