On 12/14/18 3:01 AM, Peter Eisentraut wrote:
> On 13/12/2018 20:17, David Steele wrote:
>> On 12/13/18 2:02 PM, Peter Eisentraut wrote:
>>> On 12/12/2018 05:09, David Steele wrote:
>>>> I think the patch stands on its own. Exclusive backup mode is broken
>>>> and is know to cause problems in the field.
>>>
>>> Is this breakage documented anywhere for users?
>>
>> Yes:
>>
>> https://www.postgresql.org/docs/11/continuous-archiving.html
>>
>> "Note that if the server crashes during the backup it may not be
>> possible to restart until the backup_label file has been manually
>> deleted from the PGDATA directory."
>>
>> Seems like the wording could be stronger.
>
> I think that is a pretty liberal interpretation of the word "broken".
> All this says is "if you do A, and B happens, then you need to do C".
>
> Clearly, not having to do that at all is better, but if this is all
> there is to it, then I'm confused by the characterizations of how awful
> and terrible this feature is and how we must rush to remove it.
If the server crashes during a backup, the server probably won't
restart. We say "may" here but if your backup runs more than a few
checkpoints it's more like won't. The remedy is to go manually delete a
file the user may have never heard of. They are often hesitant to do so
-- for good reason.
The downtime stretches as they call their support company or consult
Google to determine if they should really do this.
The main thing is that *manual* intervention is required to get the
cluster running again. Sure, you could automate it, but now we have
users writing scripts to delete files out of PGDATA (may as well get
tablespace_map as well) -- but hopefully not in the case of a restore
where you actually need those files. And hopefully not anything else
important.
That seems pretty broken to me.
--
-David
david@pgmasters.net