Tom Lane wrote:
> Gregory Stark <stark@enterprisedb.com> writes:
> > "Tom Lane" <tgl@sss.pgh.pa.us> writes:
> >> Whether it's a good idea or not is a bit debatable though. I'm
> >> concerned about the WAL partition filling up (--> PANIC),
> >> especially if you forget to pg_stop_backup after getting your
> >> backup.
>
> > We check if pg_start_backup in effect when we an ENOSPC error on
> > the WAL partition and if so turn it off, clean old WAL segments,
> > and march on.
>
> > The major concern being that someone might have a bad backup.
> > pg_stop_backup() could scream but they might not notice. Not sure
> > how much more we could do about that.
>
> Not putting in the foot-gun in the first place is what we could do
> about it.
AFAIK, this is a foot-gun that other databases provide, simply because
it's *very* useful when used right. But if you leave a hanging backup
process, it *will* fill your disk and eventually shut down the
database. Making sure that does not happen is a function of the backup
software and of the monitoring software.
One way I think at least MSSQL deals with it is by issuing both the
start and end backup pieces (actually they run as a single command, but
internally it's split I'm sure) over the same connection, and if that
connection goes away, it'll automatically consider the backup aborted.
I would assume the others do something similar in the caes of a crash,
but if the backup process just hangs, it will fill up the disk (I've
had this happen back when backups were actually made to tape, and the
tape ran out, for example)
//Magnus