Re: [PATCH] Don't call ereport(ERROR) from recovery target GUC assign hooks

From: JoongHyuk Shin <sjh910805(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Fujii Masao <masao(dot)fujii(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-29 09:29:59
Message-ID: CACSdjfPCPjP9tuzxgarcbkjahu-n+o+LJbUQ22aPNkOsOvrEZg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for the reviews.

v2 attached.

* Conflict check moved to a new static CheckRecoveryTargetConflicts(),
called from validateRecoveryParameters() before its early return.
It runs at every startup, so misconfiguration is caught as in master.
I kept it in startup process rather than PostmasterMain
(Greg'ssuggestion),
matching the existing recovery validation there.

* Removed each assign hook's `else recoveryTarget = UNSET` branch
(B in Fujii's framing). Fixes the empty-string clobber Fujii reported,
`recovery_target_xid='9999' + recovery_target_time=''` was silently
running with no target.
003_recovery_targets.pl now covers it (fails on v1, passes on v2).

* errdetail "may" -> "can" (Greg).

* TAP test that asserted the v1 regression is replaced with one
asserting conflict rejection at every startup.

Agreed: HEAD only, no backpatch.

--
JH Shin

On Mon, Apr 27, 2026 at 3:00 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Mon, Apr 27, 2026 at 02:36:11PM +0900, Fujii Masao wrote:
> > With the proposed patch, however, both settings are ignored and
> > recovery starts with no target. That seems unexpected to me.
>
> If that's the case (not tested myself), agreed.
> --
> Michael
>

Attachment Content-Type Size
v2-0001-Don-t-call-ereport-ERROR-from-recovery-target-GUC.patch application/octet-stream 12.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2026-04-29 09:51:55 Re: Property graph: fix error handling when dropping non-existent label property
Previous Message John Naylor 2026-04-29 09:24:50 Re: tuple radix sort