Re: Return pg_control from pg_backup_stop(). - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Return pg_control from pg_backup_stop().
Date
Msg-id CADkLM=fpAVj_YU8aU-_o8LCPTGcuQXxucoV7TXFv5vtGHmghMg@mail.gmail.com
Whole thread
In response to Re: Return pg_control from pg_backup_stop().  (David Steele <david@pgbackrest.org>)
Responses Re: Return pg_control from pg_backup_stop().
List pgsql-hackers
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. 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()). Patches apply clean, tests pass, test coverage seems sufficient, we're happy with the wording of the documentation, in short there really isn't a whole lot for us to add to the review, and for that reason we're removing our names from the list of reviewers in the commitfest app.

pgsql-hackers by date:

Previous
From: Zsolt Parragi
Date:
Subject: Re: Stack-based tracking of per-node WAL/buffer usage
Next
From: Tom Lane
Date:
Subject: Re: SQL Property Graph Queries (SQL/PGQ)