Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start
Дата
Msg-id CAH2-Wz=aNjJzOwoA1TjBvSUdqJ9uzO9L4LqcjapMz+zD0HA-+g@mail.gmail.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 Wed, Sep 18, 2024 at 1:18 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dunno ... but the OP claimed this is a case that's seen in the
> field, so maybe somebody is doing it.  On the whole I don't see
> how a btree support function can be considered not to be a low-level
> thing, so maybe restricting what it can do is the best answer.

Making it possible to do arbitrarily complicated things from B-Tree
support functions seems out of the question. We're not going to
maintain parallel versions of the code that releases buffer locks
before calling (say) the opclass ORDER proc. Just for example, how
would such a scheme work with code like _bt_check_unique?

> I fear though that the restriction can't simply be to forbid
> parallel sub-queries.

Why not?

The test case provided was intended to be illustrative of a problem
that some foreign data wrapper ran into, when it used SPI. I don't
think that the true problem was in any way related to B-Tree indexes.

--
Peter Geoghegan



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