Re: A recent message added to pg_upgade

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: amit(dot)kapila16(at)gmail(dot)com
Cc: michael(at)paquier(dot)xyz, smithpb2250(at)gmail(dot)com, bharath(dot)rupireddyforpostgres(at)gmail(dot)com, alvherre(at)alvh(dot)no-ip(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: A recent message added to pg_upgade
Date: 2023-11-09 06:10:09
Message-ID: 20231109.151009.1403545112876038004.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Thu, 9 Nov 2023 09:53:07 +0530, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote in
> Michael, Horiguchi-San, and others, do you have any thoughts on what
> is the best way to proceed?

As I previously mentioned, I believe that if rejection is to be the
course of action, it would be best to proceed with it sooner rather
than later. On the other hand, I am concerned about the need for users
to perform extra steps depending on the source cluster
conrfiguration. Therefore, another possible approach could be to
simply ignore the given settings in the assignment hook rather than
rejecting by the check hook, and forcibuly apply -1.

What do you think about this third approach?

I haven't checked this with pg_upgrade, but a standalone postmaster
would emit the following messages.

> postgres -b -c max_slot_wal_keep_size=-1
> LOG: "max_slot_wal_keep_size" is foced to set to -1 during binary upgrade mode.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
inhibit_m_s_w_k_s_during_upgrade_b_1.txt text/plain 3.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-11-09 06:18:19 Re: pg_upgrade and logical replication
Previous Message Tom Lane 2023-11-09 06:08:41 Re: Relids instead of Bitmapset * in plannode.h