| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
| Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Segmentation fault on proc exit after dshash_find_or_insert |
| Date: | 2026-01-14 15:38:00 |
| Message-ID: | 144130.1768405080@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> On Wed, Jan 14, 2026 at 6:36 PM Álvaro Herrera <alvherre(at)kurilemu(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2026-01-14 15:38:12 | Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files after relation truncation in segmented tables |
| Previous Message | Japin Li | 2026-01-14 15:35:53 | Re: Add IS_INDEX macro to brin and gist index |