Re: BUG #13559: WAL replay stuck after DROP VIEW

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Maciek Sakrejda <maciek(at)heroku(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #13559: WAL replay stuck after DROP VIEW
Date: 2015-08-11 04:19:13
Message-ID: CAB7nPqRoEo_m+tvZ8ONokncERe6ycY5K6P+Nd8ARZZPfAz-4cA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Aug 11, 2015 at 1:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Maciek Sakrejda <maciek(at)heroku(dot)com> writes:
>> On Mon, Aug 10, 2015 at 8:18 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
>> wrote:
>>> But this fixed a problem on master where queries got stuck because of
>>> the WAL insert lock patch that has been introduced in 9.4 because of a
>>> race condition between two backends.
>
>> Interesting, thanks for pointing this out.
>
> FWIW, I doubt that that particular fix is related, because in a replica
> server there are no processes performing WAL inserts.

Yes, I was more thinking about a problem where XLogFlush interacts
badly with heap_delete. But that's hard to guess anything without
looking at the backtrace and a reproducible test case...

> A stack trace of the startup process would definitely be a good thing to
> grab if/when you see this again.

Yep.
--
Michael

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Sushant Sinha 2015-08-11 04:30:16 Re: BUG #13515: Much higher disk writes after postgres upgrade 9.4.3->9.4.
Previous Message Tom Lane 2015-08-11 04:12:41 Re: BUG #13559: WAL replay stuck after DROP VIEW