Re: BUG #13559: WAL replay stuck after DROP VIEW
От | Maciek Sakrejda |
---|---|
Тема | Re: BUG #13559: WAL replay stuck after DROP VIEW |
Дата | |
Msg-id | CAKwe89BF3z7mZTEpANrR+PMmETKnEdvb7fQgjfPJK5GihbXBdw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #13559: WAL replay stuck after DROP VIEW (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: BUG #13559: WAL replay stuck after DROP VIEW
|
Список | pgsql-bugs |
On Mon, Aug 10, 2015 at 8:18 PM, Michael Paquier <michael.paquier@gmail.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.
В списке pgsql-bugs по дате отправления: