Re: Return pg_control from pg_backup_stop().

Corey Huinker <corey.huinker@gmail.com>

From: Corey Huinker <corey.huinker@gmail.com>
To: David Steele <david@pgbackrest.org>
Cc: Michael Paquier <michael@paquier.xyz>, Haibo Yan <tristan.yim@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, Fujii Masao <masao.fujii@gmail.com>
Date: 2026-03-19T04:20:40Z
Lists: pgsql-hackers
On Wed, Mar 18, 2026 at 10:56 PM David Steele <david@pgbackrest.org> wrote:

> Hi Corey,
>
> On 3/19/26 04:00, Corey Huinker wrote:
> >     Whatever gets committed for PG19 I'll write a followup patch to
> >     describe
> >     the hazards of reading pg_control and generally how to get a good
> copy.
> >     However, this will be complicated enough that the best answer will
> >     likely be to use pg_basebackup or some other reputable backup
> software.
> >     I don't love this -- I feel like the low-level interface should be
> >     usable with such hazards.
> >
> > Surya Poondla and I had decided on this patchset as a pair-reviewing
> > exercise. However, events have overtaken us, and several other people
> > have chimed in expressing the same concerns that we had observed but
> > hadn't yet completed our review.
>
> Thank you both for having a look!
>
>  > All of the main concerns that we had > found up to this point have
> been addressed in the lastest patchset,
> > except for the trivial observation that the ereport() uses the old style
> > and doesn't need the set of parens around (errmsg(), errhint()).
>
> Grep shows there are lots of messages with the new style but many more
> in the old style. Presumably they are only being updated as they are
> modified.


That's always been my assumption. Not worth the churn.


> Do you happen to know the commit or message thread where this
> policy was started? I've been searching but it is such a generic search
> term.
>

I limited my git log -p to elog.h, and it seems it started with
e3a87b4991cc back in 2020. The only reason I knew about it was that I used
to do backports from v13 to unsupported versions, and the new style would
cause the build to fail on an otherwise clean cherry pick.


> It seems to me you've still done a review. Confirming what the other
> reviewers found is good info to have.
>

Of a sort, yes, but our review doesn't touch the "is this a good idea"
question, which has been by far the thing most in need of reviewing across
the long discussion threads.