Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start
От | Tom Lane |
---|---|
Тема | Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start |
Дата | |
Msg-id | 3459938.1731007759@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start
|
Список | pgsql-bugs |
Noah Misch <noah@leadboat.com> writes: > On Thu, Nov 07, 2024 at 12:17:21PM -0500, Tom Lane wrote: >> While working on the release notes, I noticed that nothing further >> got done about this concern. What do you think of adding a test >> somewhere early in executor startup, to the effect of >> >> if (!INTERRUPTS_CAN_BE_PROCESSED()) >> ereport(ERROR, >> (errmsg("cannot start a query with interrupts disabled"))); >> >> It's definitely a band-aid, but it seems better than leaving >> things at the status quo. > That would fire in queries that don't error or hang today, so I think that > would be worse than the status quo. Good point. > This thread's previous commit just forced a serial plan. My concern is that the previous commit forced new plans to be serial, but did nothing about re-use of an existing plan. > The executor > counterpart would look like having the executor do what it does when there are > no free worker slots. Ah, that could be a way out. Stick an INTERRUPTS_CAN_BE_PROCESSED() call somewhere in there? That could even allow us to revert the planner change, which would simplify testing of the executor change. regards, tom lane
В списке pgsql-bugs по дате отправления: