Re: Invalid primary_slot_name triggers warnings in all processes on reload
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Chao Li <li.evan.chao@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-23T04:23:55Z
Lists: pgsql-hackers
On Fri, Sep 19, 2025 at 12:00 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> So I agree it's safer to free them explicitly. In the attached updated patch,
> ReplicationSlotValidateName() now pfrees err_msg and err_hint when needed.
>
+error:
+ if (elevel == 0)
+ {
+ GUC_check_errdetail("%s", err_msg);
+ if (err_hint != NULL)
+ GUC_check_errhint("%s", err_hint);
I see that other places use GUC_check_errcode. See
check_synchronous_standby_names. So, shouldn't we use it here as well?
I don't see any other place distinguishing GUC related errors in this
way. It seems the other way to differentiate throwing errors for GUC
related messages is used in call_string_check_hook and friends. It may
not be used as it is but it can give some ideas to explore. I have not
explored in detail so it may not be relevant here but it is worth
checking once.
--
With Regards,
Amit Kapila.
Commits
-
Make invalid primary_slot_name follow standard GUC error reporting.
- b00a16baeb2a 13.23 landed
- f106f53df6f5 14.20 landed
- caf529aba22d 15.15 landed
- 4fd916eab99c 16.11 landed
- 1db2870bb5ab 17.7 landed
- 6ff7ba9fe525 18.1 landed
- f33e60a53a9c 19 (unreleased) landed