From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | jd(at)commandprompt(dot)com, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_stop_backup does not complete |
Date: | 2010-02-24 00:51:01 |
Message-ID: | 3f0b79eb1002231651j18022429qdb75b0b771c8184e@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 24, 2010 at 4:49 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Maybe. But for sure, if it doesn't, and instead tells the user to
> issue pg_stop_backup(), then pg_stop_backup() had better WORK when the
> user tries to execute it. I gather that the problem is that it has to
> finish all that outstanding archiving before shutting down, in which
> case Kevin's suggestion of having a command to abort the backup seems
> reasonable. I might call it pg_abort_backup() rather than
> pg_fail_backup(), but...
Or how about adding new boolean parameter of pg_stop_backup() that
specifies whether WAL archiving needs to be waited?
pg_stop_backup([wait boolean])
This parameter is optional. If true (default), it waits for archiving.
In warm-standby and SR, we don't need to wait for archiving before starting
the standby from the base backup. So pg_stop_backup(false) would be
useful for speedup of setup of log-shipping.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2010-02-24 00:56:29 | Re: function side effects |
Previous Message | Marko Kreen | 2010-02-24 00:04:04 | Re: Pika buildfarm member failure on pgcrypto/test sha2 |