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
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 '::') |