Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica.
От | Maxim Boguk |
---|---|
Тема | Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica. |
Дата | |
Msg-id | CAK-MWwS3ecV4oXzzpX=mwGrjV_nVvmTMwG0BJatzSga2pPBBng@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica. (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: BUG #13657: Some kind of undetected deadlock between query
and "startup process" on replica.
|
Список | pgsql-bugs |
=E2=80=8B>=E2=80=8B This backtrace is not indicating that this process is waiting on a relation lock, it is resolving a recovery conflict while removing tuples, killing the virtual transaction depending on if max_standby_streaming_delay or max_standby_archive_delay are set if the conflict gets longer. Did you change the default of those parameters, which is 30s, to -1? This would mean that the standby waits indefinitely. =E2=80=8BProblem that startup process have confict with a query, which bloc= ked (waiting for) on the startup process itself (query could not process because it waiting for lock which held by startup process, and startup process waiting for finishing this query). So it's an undetected deadlock condtion here (as I understand situation). =E2=80=8B PS: there are no other activity on the database during that problem except blocked query. --=20 Maxim Boguk Senior Postgresql DBA http://www.postgresql-consulting.ru/ <http://www.postgresql-consulting.com/= > Phone RU: +7 910 405 4718 Phone AU: +61 45 218 5678 LinkedIn: http://www.linkedin.com/pub/maksym-boguk/80/b99/b1b Skype: maxim.boguk Jabber: maxim.boguk@gmail.com =D0=9C=D0=BE=D0=B9=D0=9A=D1=80=D1=83=D0=B3: http://mboguk.moikrug.ru/ "People problems are solved with people. If people cannot solve the problem, try technology. People will then wish they'd listened at the first stage."
В списке pgsql-bugs по дате отправления: