On Fri, Sep 22, 2017 at 3:46 PM, Michael Paquier
wrote:
> On Fri, Sep 22, 2017 at 3:24 PM, Masahiko Sawada
> 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
On Fri, Sep 22, 2017 at 3:24 PM, Masahiko Sawada 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.
--
Michael
On Fri, Sep 22, 2017 at 3:00 PM, Michael Paquier
wrote:
> On Fri, Sep 22, 2017 at 11:34 AM, Masahiko Sawada
> wrote:
>> You're right. I updated the patch so that it exits do_pg_abort_backup
>> if the state is NONE and setting the state to NONE in
>> do_pg_stop_backup before releasing the WAL ins
On Fri, Sep 22, 2017 at 11:34 AM, Masahiko Sawada wrote:
> You're right. I updated the patch so that it exits do_pg_abort_backup
> if the state is NONE and setting the state to NONE in
> do_pg_stop_backup before releasing the WAL insert lock.
-/* Clean up session-level lock */
+/*
+ *
On Thu, Sep 21, 2017 at 5:56 PM, Michael Paquier
wrote:
>
> Yep, but the deficiency is caused by the use before_shmem_exit() in
> the SQL-level functions present in 9.6~ which make the cleanup happen
> potentially twice. If you look at the code of basebackup.c, you would
> notice that the cleanups
On Fri, Sep 22, 2017 at 10:41 AM, Craig Ringer wrote:
> Another one to watch out for is that elog(...) and ereport(...) invoke
> CHECK_FOR_INTERRUPTS. That's given me exciting surprises before when
> combined with assertion checking and various exit cleanup hooks.
Ahah. Good point. In this case L
On 21 September 2017 at 16:56, Michael Paquier
wrote:
> On Thu, Sep 21, 2017 at 4:40 PM, Masahiko Sawada
> wrote:
> > On Thu, Sep 21, 2017 at 2:25 PM, Michael Paquier
> > wrote:
> >> On Thu, Sep 21, 2017 at 1:07 AM, Masahiko Sawada
> wrote:
> >>> The bug can happen in PostgreSQL 9.1 or higher
On Thu, Sep 21, 2017 at 5:56 PM, Michael Paquier
wrote:
> On Thu, Sep 21, 2017 at 4:40 PM, Masahiko Sawada
> wrote:
>> On Thu, Sep 21, 2017 at 2:25 PM, Michael Paquier
>> wrote:
>>> +- Assert(XLogCtl->Insert.nonExclusiveBackups >= 0);
>>> + if (XLogCtl->Insert.nonExclusiveBackups > 0)
>>> +
On Thu, Sep 21, 2017 at 4:40 PM, Masahiko Sawada wrote:
> On Thu, Sep 21, 2017 at 2:25 PM, Michael Paquier
> wrote:
>> On Thu, Sep 21, 2017 at 1:07 AM, Masahiko Sawada
>> wrote:
>>> The bug can happen in PostgreSQL 9.1 or higher that non-exclusive
>>> backup has been introduced, so we should ba
On Thu, Sep 21, 2017 at 2:25 PM, Michael Paquier
wrote:
> On Thu, Sep 21, 2017 at 1:07 AM, Masahiko Sawada
> wrote:
>> The bug can happen in PostgreSQL 9.1 or higher that non-exclusive
>> backup has been introduced, so we should back-patch to the all
>> supported versions.
>
> There is a typo he
On Thu, Sep 21, 2017 at 1:07 AM, Masahiko Sawada wrote:
> The bug can happen in PostgreSQL 9.1 or higher that non-exclusive
> backup has been introduced, so we should back-patch to the all
> supported versions.
There is a typo here right? Non-exclusive backups have been introduced
in 9.6. Why wou
Hi,
I got an assert failure when executing pg_terminate_backend to the
process that waiting for WAL to be archived in non-exclusive backup
mode.
TRAP: FailedAssertion("!(XLogCtl->Insert.nonExclusiveBackups > 0)",
File: "xlog.c", Line: 11123)
The one reproducing procedure is,
1. Start postgres wi
12 matches
Mail list logo
