Re: Return pg_control from pg_backup_stop().

On Wed, Mar 18, 2026 at 10:56 PM David Steele <david(at)pgbackrest(dot)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.