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 | 3441950.1730999841@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 Wed, Sep 18, 2024 at 12:23:42AM -0400, Tom Lane wrote: >> I do not have much faith in this patch. It assumes that the >> condition "interrupts can be processed" is the same at plan time and >> execution time. For plans extracted from the plan cache, there seems >> little reason to assume that must be true. The proposed test case >> cannot trigger that (today anyway) because SQL-language functions >> don't deal in cached plans, but I suspect it could be broken with a >> test case using a plpgsql function instead. > Good point. I missed that. 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. regards, tom lane
В списке pgsql-bugs по дате отправления: