Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start
| От | Noah Misch |
|---|---|
| Тема | Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start |
| Дата | |
| Msg-id | 20241107193823.dc.nmisch@google.com обсуждение |
| Ответ на | Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start
|
| Список | pgsql-bugs |
On Thu, Nov 07, 2024 at 02:29:19PM -0500, Tom Lane wrote: > Noah Misch <noah@leadboat.com> writes: > > 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. I agree. It solved one way of reaching the problem, leaving at least one unsolved. > > 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? Exactly. If !INTERRUPTS_CAN_BE_PROCESSED(), proceed as though no workers can be launched. > That could even allow us to revert the > planner change, which would simplify testing of the executor change. True.
В списке pgsql-bugs по дате отправления: