Horton

Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

David Steele <david@pgmasters.net>

View thread
From: David Steele <david@pgmasters.net>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@lists.postgresql.org, zxwsbg12138@gmail.com, david.zhang@highgo.ca
Date: 2023-10-27T13:31:10Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Delay recovery mode LOG after reading backup_label and/or checkpoint record

  2. Mention standby.signal in FATALs for checkpoint record missing at recovery

  3. XLOG file archiving and point-in-time recovery. There are still some

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-a7e94e2bfa4b@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