Re: BUG #15036: Un-killable queries Hanging in BgWorkerShutdown

Поиск
Список
Период
Сортировка
От David Kohn
Тема Re: BUG #15036: Un-killable queries Hanging in BgWorkerShutdown
Дата
Msg-id CAJhMaBjocndZwmSDWNsTFVurBRn7tJ5Fv1rk4+Zq-JmKrhDX8Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #15036: Un-killable queries Hanging in BgWorkerShutdown  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: BUG #15036: Un-killable queries Hanging in BgWorkerShutdown
Список pgsql-bugs


On Mon, Jan 29, 2018 at 11:08 PM Thomas Munro <thomas.munro@enterprisedb.com> wrote:

the real question is: why on earth aren't the wait loops responding to
SIGINT and SIGTERM?  I wonder if there might be something funky about
parallel query + statement timeouts.
Agreed. Seems like a backtrace wouldn't help much. I saw the other thread with similar cancellation issues a couple notes that might help: 
1) I also have a lateral select inside of a view there. seems doubtful that the lateral has anything to do with it, but in case that could be it, thought I'd pass that along. 
2) Are there any settings that could potentially help with this? for instance, this isn't on a replica, so max_standby_archive_delay wouldn't more forcefully (potentially) cancel a query, is there anything similar that could work here? as you noted we've already set a statement timeout, so it isn't responding to that, but it does get cancelled when another (hung) process is SIGKILL-ed. When that happens the db goes into recovery mode - so is it being sent SIGKILL at that point as well? Or is it some other signal that is a little less invasive? Probably not, but thought I'd ask. 

best,

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Re: BUG #15039: some question about hash index code
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #15044: materialized views incompatibility with logicalreplication in postgres 10