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