Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.
Date: 2017-11-14 17:59:05
Message-ID: CAHGQGwHmTRTZ8z0nhR4_pG_UBt59gAxihe+8jd5LqkYjquyL8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 22, 2017 at 4:42 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> On Fri, Sep 22, 2017 at 3:46 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> On Fri, Sep 22, 2017 at 3:24 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2017-11-14 18:01:05 Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Previous Message Daniel Verite 2017-11-14 17:56:23 Re: [HACKERS] SQL procedures