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