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+HiwqGzfwyYc3+tDqucYyMOS_Z6eGpYmAwfB284v1dMf+tN7A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Segmentation fault on proc exit after dshash_find_or_insert (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Segmentation fault on proc exit after dshash_find_or_insert
|
| Список | pgsql-hackers |
On Thu, Jan 15, 2026 at 12:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Amit Langote <amitlangote09@gmail.com> writes: > > On Wed, Jan 14, 2026 at 6:36 PM Álvaro Herrera <alvherre@kurilemu.de> wrote > >> 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. > > I think the idea there might be to make sure that we have released > any pre-existing hold of that lock. Otherwise this could be > a self-deadlock. Hmm, good point. Though with this patch, which adds LWLockReleaseAll() at the start of shmem_exit(), we would have already released any such lock before we get to ProcKill(). But, probably best to leave ProcKill() alone given this subtlety. -- Thanks, Amit Langote
В списке pgsql-hackers по дате отправления: