From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Alexander Kukushkin <cyberdemn(at)gmail(dot)com> |
Cc: | Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, Fabrice Chapuis <fabrice636861(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: issue with synchronized_standby_slots |
Date: | 2025-09-11 03:32:39 |
Message-ID: | CAA4eK1KJRjdEh9D-J5FrvGotU4W0zhSv50UKr3Dz29kDPeV+mA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 10, 2025 at 5:23 PM Alexander Kukushkin <cyberdemn(at)gmail(dot)com> wrote:
>
> On Wed, 10 Sept 2025 at 13:34, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com> wrote:
>>
>> I think we should also add a parsing check for slot names specified in
>> the GUC synchronize_standby_slots as suggested by Amit in [1].
>> I made the changes in the above for the same and attached the updated patch.
>
>
> I agree, validating that list contains valid replication slot names is a good idea.
> However, you used ReplicationSlotValidateName() function, which is not a good fit for it, especially when it is called with elevel=ERROR in postmaster.
>
Can you please explain why you think so? And what is your proposal for the same?
BTW, we should also try to conclude on my yesterday's point as to why
it is okay to have the same behavior for default_tablespace and
default_table_access_method and not for this parameter? I am asking
because if we change the current behavior, tomorrow, we can get
complaints that one expects the old behaviour as that was similar to
other GUCs like default_tablespace and default_table_access_method.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | shveta malik | 2025-09-11 03:47:06 | Re: Clear logical slot's 'synced' flag on promotion of standby |
Previous Message | Amit Kapila | 2025-09-11 03:13:43 | Re: Proposal: Conflict log history table for Logical Replication |