Horton

Re: A recent message added to pg_upgade

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2023-10-27T08:31:54Z
Lists: pgsql-hackers 
On 2023-Oct-27, Kyotaro Horiguchi wrote:

> @@ -1433,8 +1433,8 @@ InvalidatePossiblyObsoleteSlot(ReplicationSlotInvalidationCause cause,
>  		{
>  			ereport(ERROR,
>  					errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> -					errmsg("replication slots must not be invalidated during the upgrade"),
> -					errhint("\"max_slot_wal_keep_size\" must be set to -1 during the upgrade"));

Hmm, if I read this code right, this error is going to be thrown by the
checkpointer while finishing a checkpoint.  Fortunately, the checkpoint
record has already been written, but I don't know what would happen if
this is thrown while trying to write the shutdown checkpoint.  Probably
nothing terribly good.

I don't think this is useful.  If the setting is invalid during binary
upgrade, let's prevent it from being set at all right from the start of
the upgrade process.  In InvalidatePossiblyObsoleteSlot() we could have
just an Assert() or elog(PANIC).

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/

Commits

  1. Fix the handling of two GUCs during upgrade.

  2. Rework how logirep launchers are stopped during pg_upgrade

  3. Prohibit max_slot_wal_keep_size to value other than -1 during upgrade.

  4. Prevent startup of logical replication launcher during pg_upgrade

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