Re: File system snapshots for multiple file systems
От | Magnus Hagander |
---|---|
Тема | Re: File system snapshots for multiple file systems |
Дата | |
Msg-id | 20080408213913.6562d6cc@mha-laptop обсуждение исходный текст |
Ответ на | Re: File system snapshots for multiple file systems (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: