On Wed, Mar 18, 2026 at 10:56 PM David Steele <[email protected]> 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.
