Re: Segmentation fault on proc exit after dshash_find_or_insert
| От | Amit Langote |
|---|---|
| Тема | Re: Segmentation fault on proc exit after dshash_find_or_insert |
| Дата | |
| Msg-id | CA+HiwqG7uO2+c0AV8CWt7qG1izzN3PjdKDtgMqK9a0tiNvzHnw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Segmentation fault on proc exit after dshash_find_or_insert (Álvaro Herrera <alvherre@kurilemu.de>) |
| Ответы |
Re: Segmentation fault on proc exit after dshash_find_or_insert
Re: Segmentation fault on proc exit after dshash_find_or_insert |
| Список | pgsql-hackers |
Hi Alvaro, On Wed, Jan 14, 2026 at 6:36 PM Álvaro Herrera <alvherre@kurilemu.de> wrote > On 2025-Dec-18, Amit Langote wrote: > > > Thanks. Updated the commit message too to be more accurate in the > > attached updated patch. > > Looks good to me. Thanks for looking. > I would add an Assert(num_held_lwlocks == 0) at the > end of LWLockReleaseAll(), to make it clear that it's idempotent (which > is important for the case where ProcKill will call it again shortly > after). Makes sense. Will do. > Are you going to push this soon? Yes, I will try tomorrow. > Looking at ProcKill, I notice that we do some LWLock ops after its > LWLockReleaseAll() call, which seems a bit silly. Why not do that right > after the "if (MyProc->lockGroupLeader != NULL)" block instead? Nothing > uses LWLocks from there on. This can be a separate commit. Just to confirm: you're suggesting moving the LWLockReleaseAll() call to after the "if (MyProc->lockGroupLeader != NULL)" block? Makes sense -- odd to release all locks right before then going ahead and acquiring one. Agreed it should be a separate commit. -- Thanks, Amit Langote
В списке pgsql-hackers по дате отправления: