Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica.

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica.
Date: 2015-10-26 04:52:38
Message-ID: CAB7nPqSvo9zyab3UWPgabSSAhRYHjLPSCqmnZk_6ROiQGANj8A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sun, Oct 25, 2015 at 2:28 AM, Jeff Janes wrote:
> On Sat, Oct 24, 2015 at 4:08 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> On Sat, Oct 24, 2015 at 4:16 PM, Maxim Boguk wrote:
>>> I suppose deadlock had been happened when replay process replaying
>>> truncation to zero pages after vacuum on the master db (but it's mostly
>>> theory with no good evidence).
>>
>> By what was AccessExclusiveLock created on master? Did you run
>> TRUNCATE on those two relations from time to time?
>
> AccessExclusiveLock is automatically taken by vacuum when it thinks it
> can truncate pages off the end of the relation.

Thanks, I didn't know this one, that's in lazy_truncate_heap. Still I
don't think that this would normally deadlock except if the order of
the records was somewhat swapped: if the truncation actually happens
what is generated is XLOG_SMGR_TRUNCATE and this code path does not
perform recovery conflict checks. A XLOG_HEAP2_CLEAN record is
generated before the exclusive lock is taken for truncation.
--
Michael

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message nush2g8z 2015-10-26 08:11:07 BUG #13730: RM0jVhDZdP
Previous Message Tatsuo Ishii 2015-10-26 00:54:03 Re: Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')