From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Francesco Degrassi <francesco(dot)degrassi(at)optionfactory(dot)net>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start |
Date: | 2024-09-18 12:59:22 |
Message-ID: | CAH2-Wz=aNjJzOwoA1TjBvSUdqJ9uzO9L4LqcjapMz+zD0HA-+g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Sep 18, 2024 at 1:18 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2024-09-19 02:53:48 | Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start |
Previous Message | Muralikrishna Bandaru | 2024-09-18 12:58:07 | Re: BUG #18615: installer cannot be executed as "nt-autorität\system" |