Re: A recent message added to pg_upgade

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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: 2025-07-10 09:05:43
Message-ID: CAA4eK1L6mAG_OO4Uj2yR1BXKPLqhszC=HoLRqfZ4K63nucpkiA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 10, 2025 at 2:23 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> Few comments:
> 1) With the current approach invalidation will not happen for logical
> replication slots during upgrade operation, I felt we could retain
> this assertion just in case in the future it gets called from
> elsewhere, do you feel this assertion should be removed in the new
> approach too?
> - /*
> - * The logical replication slots shouldn't be invalidated as GUC
> - * max_slot_wal_keep_size is set to -1 and
> - * idle_replication_slot_timeout is set to 0 during the binary
> - * upgrade. See check_old_cluster_for_valid_slots()
> where we ensure
> - * that no invalidated before the upgrade.
> - */
> - Assert(!(*invalidated && SlotIsLogical(s) && IsBinaryUpgrade));
>

I don't think we need this assertion. This is a static function, and
we skipped calling this function in its caller, so it doesn't make
sense to have this assertion.

> 2) Documentation
> 2.a) Currently slot invalidation will not happen during upgrade
> because of idle_replication_slot_timeout, do you feel we should add a
> note in documentation or is it ok not to mention?
> 2.b) Currently WAL removal will not happen during upgrade because of
> max_slot_wal_keep_size, should we add a note about this.
>

We skip or do a few special things in other parts of the code during
BinaryUpgrade, but don't mention those, so don't think we need to
mention this one as well.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yugo Nagata 2025-07-10 09:17:01 Re: Suggestion to add --continue-client-on-abort option to pgbench
Previous Message jian he 2025-07-10 08:53:28 Re: SQL:2023 JSON simplified accessor support