From: | Maciek Sakrejda <maciek(at)heroku(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #13559: WAL replay stuck after DROP VIEW |
Date: | 2015-08-11 04:03:20 |
Message-ID: | CAKwe89BF3z7mZTEpANrR+PMmETKnEdvb7fQgjfPJK5GihbXBdw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
Do you have some remnants of the logs when this problem happened? Or
> even better, a stack trace to understand where the startup process got
> stucked? That's perhaps unrelated, but were you using commit_delay?
>
We do have logs from the primary and the replica, but I can't share them
directly. Is there anything specific I should look for? Unfortunately, I
did not think to take a stack trace from the startup process. And
commit_delay is not set.
I have been playing with pgbench, creating and dropping views with a
> couple of hundred connections on 9.4.1 but could not reproduce the
> issue.
>
Thanks for trying it out. Were you running queries against these views on
the replica when dropping/recreating them on the primary? I was guessing
maybe the lock interplay there had something to do with it, although I
admit my understanding of these mechanisms is pretty superficial.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-08-11 04:12:41 | Re: BUG #13559: WAL replay stuck after DROP VIEW |
Previous Message | Michael Paquier | 2015-08-11 03:18:05 | Re: BUG #13559: WAL replay stuck after DROP VIEW |