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
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 |