Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.
От | Fujii Masao |
---|---|
Тема | Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted. |
Дата | |
Msg-id | CAHGQGwHmTRTZ8z0nhR4_pG_UBt59gAxihe+8jd5LqkYjquyL8g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted. (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | pgsql-hackers |
On Fri, Sep 22, 2017 at 4:42 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: > On Fri, Sep 22, 2017 at 3:46 PM, Michael Paquier > <michael.paquier@gmail.com> wrote: >> On Fri, Sep 22, 2017 at 3:24 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: >>> I have a question. Since WALInsertLockRelease seems not to call >>> LWLockWaitForVar I thought you wanted to mean LWLockReleaseClearVar >>> instead, is that right? >> >> This looks like a copy-pasto from my side. Thanks for spotting it. > > Okay, attached the latest version patch. + /* Quick exit if we have done the backup */ + if (XLogCtl->Insert.exclusiveBackupState == EXCLUSIVE_BACKUP_NONE) + return; This quick exit seems to cause another problem. Please imagine the case where there is no exclusive backup running, a backend starts non-exclusive backup and is terminated before calling pg_stop_backup(). In this case, do_pg_abort_backup() should decrement XLogCtl->Insert.nonExclusiveBackups, but, with the patch, because of the above quick exit, do_pg_abort_backup() fails to decrement that. Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: