On 10/27/23 03:22, Michael Paquier wrote:
On Mon, Oct 16, 2023 at 02:54:35PM +0900, Michael Paquier wrote:
On Sat, Oct 14, 2023 at 03:45:33PM -0400, David Steele wrote:
On 9/28/23 19:59, Michael Paquier wrote:
Another idea I had was to force the creation of recovery.signal by
pg_basebackup even if -R is not used. All the reports we've seen with
people getting confused came from pg_basebackup that enforces no
configuration.
This change makes it more obvious if configuration is missing (since you'll
get an error), however +1 for adding this to pg_basebackup.
Looking at the streaming APIs of pg_basebackup, it looks like this
would be a matter of using bbstreamer_inject_file() to inject an empty
file into the stream. Still something seems to be off once
compression methods are involved.. Hmm. I am not sure. Well, this
could always be done as a patch independant of this one, under a
separate discussion. There are extra arguments about whether it would
be a good idea to add a recovery.signal even when taking a backup from
a standby, and do that only in 17~.
Hmm. On this specific point, it would actually be much simpler to
force recovery.signal to be in the contents streamed to a BASE_BACKUP.
That sounds like the right plan to me. Nice and simple.
This does not step on your proposal at [1], though, because you'd
still require a .signal file for recovery as far as I understand :/
[1]:
https://www.postgresql.org/message-id/2daf8adc-8db7-4204-a7f2-a7e94e2bf...@pgmasters.net
Yes.
Would folks be OK to move on with the patch of this thread at the end?
I am attempting a last-call kind of thing.
I'm still +1 for the patch as it stands.
Regards,
-David
