Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start
От | Francesco Degrassi |
---|---|
Тема | Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start |
Дата | |
Msg-id | CAC-SaSzTBHeOF2-K117XKS5UZU=Tibn-zZMRqPRGptgvfxWRrg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start (Noah Misch <noah@leadboat.com>) |
Список | pgsql-bugs |
On Thu, 19 Sept 2024 at 04:53, Noah Misch <noah@leadboat.com> wrote: > For what it's worth, I tried making standard_ExecutorStart() warn if > !INTERRUPTS_CAN_BE_PROCESSED(). Only this thread's new test and > 004_verify_nbtree_unique reached the warning. (That's not a surprise.) The reproducer I provided is actually a minimization of 004_verify_nbtree_unique, so it's just the one case actually. > On Wed, Sep 18, 2024 at 08:59:22AM -0400, Peter Geoghegan wrote: > > The test case provided was intended to be illustrative of a problem > > that some foreign data wrapper ran into, when it used SPI. > > Ideally, we'd block those or at least warn under assertions so FDW authors > don't accidentally run the executor with an LWLock held. Unlike the opclass > case, we so far don't have a valid use case for holding an LWLock there. In > other words, if the opclass use case is the only known-valid one, it would be > nice to have checks so new use cases don't creep in. My 2c as a FDW developer, having a warning when calling into the SPI with a LWLock held would have allowed us to identify this issue months ago, well before we stumbled into a parallel plan and hang. Best regards -- Francesco
В списке pgsql-bugs по дате отправления: