Re: Remove Deprecated Exclusive Backup Mode

On Fri, Dec 14, 2018 at 8:27 AM David Steele <david(at)pgmasters(dot)net> wrote:
> 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.

Sure. So it's broken in the sense that if you don't read and
carefully follow the directions, you will have problems. But that's
also true of an automobile, a power saw, the DELETE command,
antibiotics, and the Internal Revenue Code. Many things in life are
complicated and require due caution, and yet people regularly navigate
things that are VASTLY more complicated than "if the server crashes
during a hot backup, remove this file." Especially because if we
subsequently fail for this reason, we give you a very precise hint
that tells you exactly what to do:

HINT: If you are not restoring from a backup, try removing the file
"<path to $PGDATA goes here>/backup_label"

Now, I grant that emitting a HINT telling you exactly what to do is
not as good as not requiring manual user invention in the first place,
but it's not like we're requiring you to carry out some byzantine
process that nobody can possible understand. The "if" condition here
is one that any DBA should be able to understand: am I, or am I not,
in the process of restoring a backup? The system does not know, but
the DBA should. And once you know that the answer is "no, I'm not
restoring a backup", then you just remove the exact pathname indicated
and try it again and everything works fine.

Peter's complaint -- that this is a pretty liberal reading of the word
"broken" -- is IMHO very well put. Saying that something is broken
means it doesn't work. But the exclusive backup mode works fine if
used according to the directions. The fact that people often get
confused and don't follow the directions, and that the directions tend
to end up requiring manual intervention after a system crash, is
unfortunate, and it is why we have a new API. But "that thing isn't
as well designed as it could've been" is not the same thing as "that
thing does not work when used as designed," no matter how much you
keep insisting the contrary. It does work. It has worked for a long
time. Many people have used it successfully. It was the ONLY way of
doing this for many years. There is no necessary reason why it has to
be a huge problem, and I don't think it is.

In my experience with EnterpriseDB customers, this IS an occasional
source of confusion, but there are other things that are a problem a
lot more frequently, like work_mem, which you often can't set high
enough to get good query performance without causing OOM events when
the system gets busy. I'd hesitate to call work_mem broken, but a GUC
for which no single value both adequately protects against OOM and
gives workable performance is closer to broken than an exclusive
backup mode, which actually does work - albeit with occasional manual
intervention - if you read and follow the directions.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company