Re: detecting binary backup in progress
От | Andres Freund |
---|---|
Тема | Re: detecting binary backup in progress |
Дата | |
Msg-id | 20130601151427.GA6732@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: detecting binary backup in progress (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: detecting binary backup in progress
|
Список | pgsql-hackers |
On 2013-06-01 08:11:26 -0700, Joe Conway wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/01/2013 02:43 AM, Christoph Moench-Tegeder wrote: > > ## Joe Conway (mail@joeconway.com): > > > >> However there is a period of time after pg_start_backup() is > >> first executed to when it completes, during which backup_label > >> file does not exist yet, but the backup has essentially been > >> started. Is there any way to detect this state? > > > > When I did some research on the very same question just a few > > weeks ago, I settled for external locks (lockfile, > > pg_advisory_lock(), ..., depending on your exact situation) around > > the backup-taking code. > > Right, and an external lockfile is good except there is a race condition. > > Proc1, t0) SELECT pg_start_backup(...) -- command starts to execute > > Proc2, t1) lay down a lockfile (or other mechanism) > > Proc2, t2) check for running backup by looking for backup_label > > Proc1, t3) SELECT pg_start_backup(...) -- command finishes, > -- backup_label created > > So you are forced to sleep for some arbitrary time just in case > pg_start_backup() has started but not completed at the point when you > try to lock out the backup. Uh. Why would you do the lock(file) thingy *after* calling pg_start_backup? You should do lock before calling start backup and remove the lock after calling stop backup. In that case I don't see where the race condition is? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: