| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | JoongHyuk Shin <sjh910805(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Don't call ereport(ERROR) from recovery target GUC assign hooks |
| Date: | 2026-04-27 01:52:03 |
| Message-ID: | ae7BQx5D6Y-E2Dqu@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Apr 24, 2026 at 10:08:04PM +0900, Fujii Masao wrote:
> In the master, when the following two recovery targets are specified,
> the recovery target assign hook detects that multiple targets were given
> and reports an error. With the patch, however, the same settings do not
> raise an error, recoveryTarget is set to RECOVERY_TARGET_UNSET, and
> recovery unexpectedly proceeds with no target. Could this be a bug
> in the patch?
>
> recovery_target_xid = '9999'
> recovery_target_time = ''
Don't think so. You are specifying for recovery_target_time the same
thing as the default, as in "I don't know and do nothing about the
time". Why would it matter to make the difference between a default
value set and what's stored by default if nothing is set in this case?
FWIW, I am wondering if we should seriously consider this stuff as
candidate for a backpatch because this is a design mistake: we should
never *ever* rely on the GUC hooks to do cross-checks of multiple
values, f2cbffc7a618 deciding that it was a right thing to do. It's
not. The risk of breaking something may not justify that a backpatch.
+1 for reworking that on HEAD, at least.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-04-27 01:54:04 | Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects |
| Previous Message | Michael Paquier | 2026-04-27 00:50:28 | Re: Fix bug with accessing to temporary tables of other sessions |