From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, michael(at)paquier(dot)xyz |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, zxwsbg12138(at)gmail(dot)com, david(dot)zhang(at)highgo(dot)ca |
Subject: | Re: Requiring recovery.signal or standby.signal when recovering with a backup_label |
Date: | 2023-09-28 20:23:42 |
Message-ID: | 4f94351c-24e2-cf32-82d3-1e1bf89a0f5e@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/27/23 23:58, Kyotaro Horiguchi wrote:
> At Fri, 10 Mar 2023 15:59:04 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
>> My apologies for the long message, but this deserves some attention,
>> IMHO.
>>
>> So, any thoughts?
>
> Sorry for being late. However, I agree with David's concern regarding
> the unnecessary inconvenience it introduces. I'd like to maintain the
> functionality.
After some playing around, I find I agree with Michael on this, i.e.
require at least standby.signal when a backup_label is present.
According to my testing, you can preserve the "independent server"
functionality by setting archive_command = /bin/false. In this case the
timeline is not advanced and recovery proceeds from whatever is
available in pg_wal.
I think this type of recovery from a backup label without a timeline
change should absolutely be the exception, not the default as it seems
to be now. If the server is truly independent, then the timeline change
is not important. If the server is not independent, then the timeline
change is critical.
So overall, +1 for Michael's patch, though I have only read through it
and not tested it yet.
One comment, though, if we are going to require recovery.signal when
backup_label is present, should it just be implied? Why error and force
the user to create it?
Regards,
-David
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-09-28 20:32:13 | Re: Annoying build warnings from latest Apple toolchain |
Previous Message | Tom Lane | 2023-09-28 20:18:34 | Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges |