From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: [COMMITTERS] pgsql: Fix an assertion failure related to an exclusive backup. |
Date: | 2017-01-17 14:42:55 |
Message-ID: | CAHGQGwFWm1a7pAODfC4uWKbn7yuLEavBkSeGyXJgCp9xkgGHFQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Tue, Jan 17, 2017 at 10:37 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Tue, Jan 17, 2017 at 5:40 PM, Fujii Masao <fujii(at)postgresql(dot)org> wrote:
>> Fix an assertion failure related to an exclusive backup.
>>
>> Previously multiple sessions could execute pg_start_backup() and
>> pg_stop_backup() to start and stop an exclusive backup at the same time.
>> This could trigger the assertion failure of
>> "FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)".
>> This happend because, even while pg_start_backup() was starting
>> an exclusive backup, other session could run pg_stop_backup()
>> concurrently and mark the backup as not-in-progress unconditionally.
>>
>> This patch introduces ExclusiveBackupState indicating the state of
>> an exclusive backup. This state is used to ensure that there is only
>> one session running pg_start_backup() or pg_stop_backup() at
>> the same time, to avoid the assertion failure.
>
> Please note that this commit message is not completely exact. This fix
> does not only avoid triggerring this assertion failure, it also makes
> sure that no manual on-disk intervention is needed by the user to
> remove a backup_label file after a failure of pg_stop_backup(). Before
> this patch, what happened is that the exclusive backup counter in
> XLogCtl got decremented before removing backup_label. However, after
> the counter was decremented, if an error occurred, the shared memory
> counter would have been at 0 with a backup_label file on disk.
> Subsequent attempts to start pg_start_backup() would have failed, and
> putting the system backup into a consistent state would have required
> an operator to remove by hand the backup_label file. The heart of the
> logic here is in the callback of pg_stop_backup() when an error
> happens during the deletion of the backup_label file.
With the patch, what happens if pg_stop_backup exits with an error
after removing backup_label file before resetting the backup state
to none?
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-01-17 15:05:18 | pgsql: doc: Update URL for Microsoft download site |
Previous Message | Michael Paquier | 2017-01-17 13:37:30 | Re: [COMMITTERS] pgsql: Fix an assertion failure related to an exclusive backup. |
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Langille | 2017-01-17 14:55:34 | reminder: PGCon 2017 CFP |
Previous Message | Merlin Moncure | 2017-01-17 14:20:25 | Re: New CORRESPONDING clause design |