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 по дате отправления: