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

Thanks for the reviews.

v3 attached.

Expected behavior matrix:

Same GUC, non-empty then empty -> the empty wins; target unset
Same GUC, empty then non-empty -> the non-empty wins; target set
Cross-GUC, both non-empty -> error (multiple recovery targets)
Cross-GUC, one empty -> the non-empty GUC's target stands
All empty -> no target, end-of-WAL recovery

* Restored same-GUC last-wins (row 1). v2 dropped each hook's
`else recoveryTarget = UNSET`; v3 narrows it to
`else if (recoveryTarget == MY_TYPE)`.

* Cross-GUC empty stays a no-op (row 4), as v2 introduced.
Strict reject via a source-aware variant is feasible
if reviewers prefer.

* 003_recovery_targets.pl gains seven CLI-path cases;
postgresql.conf dedup cannot exercise the same-GUC clear path.

--
JH Shin

On Fri, May 1, 2026 at 2:53 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Wed, Apr 29, 2026 at 6:30 PM JoongHyuk Shin <sjh910805(at)gmail(dot)com>
> wrote:
> >
> > Thanks for the reviews.
> >
> > v2 attached.
>
> Thanks for updating the patch!
>
> When I started postgres with the following command, recovery_target_xid was
> treated as unset in the master, but with the patch the
> recovery_target_xid=700
> setting was used instead. This behavior seems unexpected to me. Thoughts?
>
> postgres -D data -c "recovery_target_xid=700" -c "recovery_target_xid="
>
> Regards,
>
>
> --
> Fujii Masao
>