Re: [PATCH] Don't call ereport(ERROR) from recovery target GUC assign hooks
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: JoongHyuk Shin <sjh910805@gmail.com>
Cc: Zsolt Parragi <zsolt.parragi@percona.com>, pgsql-hackers@lists.postgresql.org
Date: 2026-07-07T06:58:18Z
Lists: pgsql-hackers
On Tue, Jul 07, 2026 at 12:01:59PM +0900, JoongHyuk Shin wrote:
> Attached v8 with the errhint removed. No other changes from v7.
+ errmsg("multiple recovery targets specified"),
+ errdetail("Only one recovery target can be set. Parameters set: %s.",
+ buf.data));
FWIW, I think that this is redundant, as the errmsg and the errdetail
are basically saying the same thing. I'd suggest a simpler:
errmsg: cannot specify more than one recovery target
errdetail: Parameters set are: %s.
+# that does not clear another GUC's target. Conflicts are detected at every
+# server start by DetermineRecoveryTargetType().
We don't really care about the function name here, just that multiple
targets are blocked.
+# LSN after the final 6000-row insert and WAL switch. The set-then-clear case
+# below has no recovery target and replays all WAL, so it polls on this instead
+# of $lsn5, which would race the 5001-6000 rows.
I smell of an AI set of comments. We could just remove the whole and
not lose value in understanding the meaning of the test. A bunch of
the comments added to the TAP script could also be trimmed down quite
a bit, made simpler..
With recovery_target assign hook being removed for the case of
immediate, a test case that checks for a conflict between immediate
and a secondary target may be in order.
Please note that Fujii-san is registered as a committer of this patch,
so I am not planning to go beyond a review here.
--
Michael