Re: A recent message added to pg_upgade

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, smithpb2250(at)gmail(dot)com, bharath(dot)rupireddyforpostgres(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: A recent message added to pg_upgade
Date: 2023-11-09 14:24:23
Message-ID: 202311091424.s6dakq7zg5fl@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2023-Nov-09, Amit Kapila wrote:

> These comments appear mostly repetitive to what is already mentioned
> in start_postmaster(). So, I have changed those referred to already
> written comments, and slightly adjusted the comments at another place.
> See attached.

I'd still rather mention check_old_cluster_for_valid_slots() just above
the Assert() in InvalidatePossiblyObsoleteSlot(). It looks too bare to
me otherwise.

> Personally, I don't see the need for a test for this, so removed the
> same but can add it back if you or others think so.

I'm neutral on having a test for this. I'm not sure this is easy to
break unintentionally. OTOH the test is cheap, since it only has to run
pg_upgrade itself and not, say, another initdb. On the (as Robert says)
third hand, would we have tests for each possible GUC that we'd like not
to be changed during pg_upgrade? I suspect not, which suggests we don't
want this one either.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"El Maquinismo fue proscrito so pena de cosquilleo hasta la muerte"
(Ijon Tichy en Viajes, Stanislaw Lem)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2023-11-09 14:26:10 Re: proposal: possibility to read dumped table's name from file
Previous Message Drouvot, Bertrand 2023-11-09 13:59:43 Re: Synchronizing slots from primary to standby