pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Fix segfault from releasing locks in detached DSM segments
8+ messages / 3 participants
[nested] [flat]
* pgsql: Fix segfault from releasing locks in detached DSM segments
@ 2026-01-16 04:26 Amit Langote <amitlan@postgresql.org>
0 siblings, 1 reply; 8+ messages in thread
From: Amit Langote @ 2026-01-16 04:26 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix segfault from releasing locks in detached DSM segments
If a FATAL error occurs while holding a lock in a DSM segment (such
as a dshash lock) and the process is not in a transaction, a
segmentation fault can occur during process exit.
The problem sequence is:
1. Process acquires a lock in a DSM segment (e.g., via dshash)
2. FATAL error occurs outside transaction context
3. proc_exit() begins, calling before_shmem_exit callbacks
4. dsm_backend_shutdown() detaches all DSM segments
5. Later, on_shmem_exit callbacks run
6. ProcKill() calls LWLockReleaseAll()
7. Segfault: the lock being released is in unmapped memory
This only manifests outside transaction contexts because
AbortTransaction() calls LWLockReleaseAll() during transaction
abort, releasing locks before DSM cleanup. Background workers and
other non-transactional code paths are vulnerable.
Fix by calling LWLockReleaseAll() unconditionally at the start of
shmem_exit(), before any callbacks run. Releasing locks before
callbacks prevents the segfault - locks must be released before
dsm_backend_shutdown() detaches their memory. This is safe because
after an error, held locks are protecting potentially inconsistent
data anyway, and callbacks can acquire fresh locks if needed.
Also add a comment noting that LWLockReleaseAll() must be safe to
call before LWLock initialization (which it is, since
num_held_lwlocks will be 0), plus an Assert for the post-condition.
This fix aligns with the original design intent from commit
001a573a2, which noted that backends must clean up shared memory
state (including releasing lwlocks) before unmapping dynamic shared
memory segments.
Reported-by: Rahila Syed <rahilasyed90@gmail.com>
Author: Rahila Syed <rahilasyed90@gmail.com>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>
Discussion: https://postgr.es/m/CAH2L28uSvyiosL+kaic9249jRVoQiQF6JOnaCitKFq=xiFzX3g@mail.gmail.com
Backpatch-through: 14
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/9cbb1d21d67ec3cb2d5342073d220a0c1e0ad82c
Modified Files
--------------
src/backend/storage/ipc/ipc.c | 11 +++++++++--
src/backend/storage/lmgr/lwlock.c | 6 ++++++
2 files changed, 15 insertions(+), 2 deletions(-)
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: pgsql: Fix segfault from releasing locks in detached DSM segments
@ 2026-01-16 04:45 Tom Lane <tgl@sss.pgh.pa.us>
parent: Amit Langote <amitlan@postgresql.org>
0 siblings, 1 reply; 8+ messages in thread
From: Tom Lane @ 2026-01-16 04:45 UTC (permalink / raw)
To: Amit Langote <amitlan@postgresql.org>; +Cc: pgsql-committers@lists.postgresql.org
Amit Langote <amitlan@postgresql.org> writes:
> Fix segfault from releasing locks in detached DSM segments
> ...
> Backpatch-through: 14
I see no back-patch commits?
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
* pgsql: Fix segfault from releasing locks in detached DSM segments
@ 2026-01-16 05:45 Amit Langote <amitlan@postgresql.org>
0 siblings, 0 replies; 8+ messages in thread
From: Amit Langote @ 2026-01-16 05:45 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix segfault from releasing locks in detached DSM segments
If a FATAL error occurs while holding a lock in a DSM segment (such
as a dshash lock) and the process is not in a transaction, a
segmentation fault can occur during process exit.
The problem sequence is:
1. Process acquires a lock in a DSM segment (e.g., via dshash)
2. FATAL error occurs outside transaction context
3. proc_exit() begins, calling before_shmem_exit callbacks
4. dsm_backend_shutdown() detaches all DSM segments
5. Later, on_shmem_exit callbacks run
6. ProcKill() calls LWLockReleaseAll()
7. Segfault: the lock being released is in unmapped memory
This only manifests outside transaction contexts because
AbortTransaction() calls LWLockReleaseAll() during transaction
abort, releasing locks before DSM cleanup. Background workers and
other non-transactional code paths are vulnerable.
Fix by calling LWLockReleaseAll() unconditionally at the start of
shmem_exit(), before any callbacks run. Releasing locks before
callbacks prevents the segfault - locks must be released before
dsm_backend_shutdown() detaches their memory. This is safe because
after an error, held locks are protecting potentially inconsistent
data anyway, and callbacks can acquire fresh locks if needed.
Also add a comment noting that LWLockReleaseAll() must be safe to
call before LWLock initialization (which it is, since
num_held_lwlocks will be 0), plus an Assert for the post-condition.
This fix aligns with the original design intent from commit
001a573a2, which noted that backends must clean up shared memory
state (including releasing lwlocks) before unmapping dynamic shared
memory segments.
Reported-by: Rahila Syed <rahilasyed90@gmail.com>
Author: Rahila Syed <rahilasyed90@gmail.com>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>
Discussion: https://postgr.es/m/CAH2L28uSvyiosL+kaic9249jRVoQiQF6JOnaCitKFq=xiFzX3g@mail.gmail.com
Backpatch-through: 14
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/f6df78173ef514903dfc8cba2b89a5c2c6abf785
Modified Files
--------------
src/backend/storage/ipc/ipc.c | 11 +++++++++--
src/backend/storage/lmgr/lwlock.c | 6 ++++++
2 files changed, 15 insertions(+), 2 deletions(-)
^ permalink raw reply [nested|flat] 8+ messages in thread
* pgsql: Fix segfault from releasing locks in detached DSM segments
@ 2026-01-16 05:46 Amit Langote <amitlan@postgresql.org>
0 siblings, 0 replies; 8+ messages in thread
From: Amit Langote @ 2026-01-16 05:46 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix segfault from releasing locks in detached DSM segments
If a FATAL error occurs while holding a lock in a DSM segment (such
as a dshash lock) and the process is not in a transaction, a
segmentation fault can occur during process exit.
The problem sequence is:
1. Process acquires a lock in a DSM segment (e.g., via dshash)
2. FATAL error occurs outside transaction context
3. proc_exit() begins, calling before_shmem_exit callbacks
4. dsm_backend_shutdown() detaches all DSM segments
5. Later, on_shmem_exit callbacks run
6. ProcKill() calls LWLockReleaseAll()
7. Segfault: the lock being released is in unmapped memory
This only manifests outside transaction contexts because
AbortTransaction() calls LWLockReleaseAll() during transaction
abort, releasing locks before DSM cleanup. Background workers and
other non-transactional code paths are vulnerable.
Fix by calling LWLockReleaseAll() unconditionally at the start of
shmem_exit(), before any callbacks run. Releasing locks before
callbacks prevents the segfault - locks must be released before
dsm_backend_shutdown() detaches their memory. This is safe because
after an error, held locks are protecting potentially inconsistent
data anyway, and callbacks can acquire fresh locks if needed.
Also add a comment noting that LWLockReleaseAll() must be safe to
call before LWLock initialization (which it is, since
num_held_lwlocks will be 0), plus an Assert for the post-condition.
This fix aligns with the original design intent from commit
001a573a2, which noted that backends must clean up shared memory
state (including releasing lwlocks) before unmapping dynamic shared
memory segments.
Reported-by: Rahila Syed <rahilasyed90@gmail.com>
Author: Rahila Syed <rahilasyed90@gmail.com>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>
Discussion: https://postgr.es/m/CAH2L28uSvyiosL+kaic9249jRVoQiQF6JOnaCitKFq=xiFzX3g@mail.gmail.com
Backpatch-through: 14
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/b926ff1373bbd5bd012c5e4e6465a7fd9d034966
Modified Files
--------------
src/backend/storage/ipc/ipc.c | 11 +++++++++--
src/backend/storage/lmgr/lwlock.c | 6 ++++++
2 files changed, 15 insertions(+), 2 deletions(-)
^ permalink raw reply [nested|flat] 8+ messages in thread
* pgsql: Fix segfault from releasing locks in detached DSM segments
@ 2026-01-16 05:46 Amit Langote <amitlan@postgresql.org>
0 siblings, 0 replies; 8+ messages in thread
From: Amit Langote @ 2026-01-16 05:46 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix segfault from releasing locks in detached DSM segments
If a FATAL error occurs while holding a lock in a DSM segment (such
as a dshash lock) and the process is not in a transaction, a
segmentation fault can occur during process exit.
The problem sequence is:
1. Process acquires a lock in a DSM segment (e.g., via dshash)
2. FATAL error occurs outside transaction context
3. proc_exit() begins, calling before_shmem_exit callbacks
4. dsm_backend_shutdown() detaches all DSM segments
5. Later, on_shmem_exit callbacks run
6. ProcKill() calls LWLockReleaseAll()
7. Segfault: the lock being released is in unmapped memory
This only manifests outside transaction contexts because
AbortTransaction() calls LWLockReleaseAll() during transaction
abort, releasing locks before DSM cleanup. Background workers and
other non-transactional code paths are vulnerable.
Fix by calling LWLockReleaseAll() unconditionally at the start of
shmem_exit(), before any callbacks run. Releasing locks before
callbacks prevents the segfault - locks must be released before
dsm_backend_shutdown() detaches their memory. This is safe because
after an error, held locks are protecting potentially inconsistent
data anyway, and callbacks can acquire fresh locks if needed.
Also add a comment noting that LWLockReleaseAll() must be safe to
call before LWLock initialization (which it is, since
num_held_lwlocks will be 0), plus an Assert for the post-condition.
This fix aligns with the original design intent from commit
001a573a2, which noted that backends must clean up shared memory
state (including releasing lwlocks) before unmapping dynamic shared
memory segments.
Reported-by: Rahila Syed <rahilasyed90@gmail.com>
Author: Rahila Syed <rahilasyed90@gmail.com>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>
Discussion: https://postgr.es/m/CAH2L28uSvyiosL+kaic9249jRVoQiQF6JOnaCitKFq=xiFzX3g@mail.gmail.com
Backpatch-through: 14
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/980b7c7369e44e49078ad2bbb39e7012347a0919
Modified Files
--------------
src/backend/storage/ipc/ipc.c | 11 +++++++++--
src/backend/storage/lmgr/lwlock.c | 6 ++++++
2 files changed, 15 insertions(+), 2 deletions(-)
^ permalink raw reply [nested|flat] 8+ messages in thread
* pgsql: Fix segfault from releasing locks in detached DSM segments
@ 2026-01-16 05:46 Amit Langote <amitlan@postgresql.org>
0 siblings, 0 replies; 8+ messages in thread
From: Amit Langote @ 2026-01-16 05:46 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix segfault from releasing locks in detached DSM segments
If a FATAL error occurs while holding a lock in a DSM segment (such
as a dshash lock) and the process is not in a transaction, a
segmentation fault can occur during process exit.
The problem sequence is:
1. Process acquires a lock in a DSM segment (e.g., via dshash)
2. FATAL error occurs outside transaction context
3. proc_exit() begins, calling before_shmem_exit callbacks
4. dsm_backend_shutdown() detaches all DSM segments
5. Later, on_shmem_exit callbacks run
6. ProcKill() calls LWLockReleaseAll()
7. Segfault: the lock being released is in unmapped memory
This only manifests outside transaction contexts because
AbortTransaction() calls LWLockReleaseAll() during transaction
abort, releasing locks before DSM cleanup. Background workers and
other non-transactional code paths are vulnerable.
Fix by calling LWLockReleaseAll() unconditionally at the start of
shmem_exit(), before any callbacks run. Releasing locks before
callbacks prevents the segfault - locks must be released before
dsm_backend_shutdown() detaches their memory. This is safe because
after an error, held locks are protecting potentially inconsistent
data anyway, and callbacks can acquire fresh locks if needed.
Also add a comment noting that LWLockReleaseAll() must be safe to
call before LWLock initialization (which it is, since
num_held_lwlocks will be 0), plus an Assert for the post-condition.
This fix aligns with the original design intent from commit
001a573a2, which noted that backends must clean up shared memory
state (including releasing lwlocks) before unmapping dynamic shared
memory segments.
Reported-by: Rahila Syed <rahilasyed90@gmail.com>
Author: Rahila Syed <rahilasyed90@gmail.com>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>
Discussion: https://postgr.es/m/CAH2L28uSvyiosL+kaic9249jRVoQiQF6JOnaCitKFq=xiFzX3g@mail.gmail.com
Backpatch-through: 14
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/4071fe900e67a801f16ee9b4843e5fbe82584a44
Modified Files
--------------
src/backend/storage/ipc/ipc.c | 11 +++++++++--
src/backend/storage/lmgr/lwlock.c | 6 ++++++
2 files changed, 15 insertions(+), 2 deletions(-)
^ permalink raw reply [nested|flat] 8+ messages in thread
* pgsql: Fix segfault from releasing locks in detached DSM segments
@ 2026-01-16 05:46 Amit Langote <amitlan@postgresql.org>
0 siblings, 0 replies; 8+ messages in thread
From: Amit Langote @ 2026-01-16 05:46 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix segfault from releasing locks in detached DSM segments
If a FATAL error occurs while holding a lock in a DSM segment (such
as a dshash lock) and the process is not in a transaction, a
segmentation fault can occur during process exit.
The problem sequence is:
1. Process acquires a lock in a DSM segment (e.g., via dshash)
2. FATAL error occurs outside transaction context
3. proc_exit() begins, calling before_shmem_exit callbacks
4. dsm_backend_shutdown() detaches all DSM segments
5. Later, on_shmem_exit callbacks run
6. ProcKill() calls LWLockReleaseAll()
7. Segfault: the lock being released is in unmapped memory
This only manifests outside transaction contexts because
AbortTransaction() calls LWLockReleaseAll() during transaction
abort, releasing locks before DSM cleanup. Background workers and
other non-transactional code paths are vulnerable.
Fix by calling LWLockReleaseAll() unconditionally at the start of
shmem_exit(), before any callbacks run. Releasing locks before
callbacks prevents the segfault - locks must be released before
dsm_backend_shutdown() detaches their memory. This is safe because
after an error, held locks are protecting potentially inconsistent
data anyway, and callbacks can acquire fresh locks if needed.
Also add a comment noting that LWLockReleaseAll() must be safe to
call before LWLock initialization (which it is, since
num_held_lwlocks will be 0), plus an Assert for the post-condition.
This fix aligns with the original design intent from commit
001a573a2, which noted that backends must clean up shared memory
state (including releasing lwlocks) before unmapping dynamic shared
memory segments.
Reported-by: Rahila Syed <rahilasyed90@gmail.com>
Author: Rahila Syed <rahilasyed90@gmail.com>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>
Discussion: https://postgr.es/m/CAH2L28uSvyiosL+kaic9249jRVoQiQF6JOnaCitKFq=xiFzX3g@mail.gmail.com
Backpatch-through: 14
Branch
------
REL_18_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/1943ceb38842ada55f13630f989c78184e82a397
Modified Files
--------------
src/backend/storage/ipc/ipc.c | 11 +++++++++--
src/backend/storage/lmgr/lwlock.c | 6 ++++++
2 files changed, 15 insertions(+), 2 deletions(-)
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: pgsql: Fix segfault from releasing locks in detached DSM segments
@ 2026-01-16 05:47 Amit Langote <amitlangote09@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 8+ messages in thread
From: Amit Langote @ 2026-01-16 05:47 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Amit Langote <amitlan@postgresql.org>; pgsql-committers@lists.postgresql.org
On Fri, Jan 16, 2026 at 1:45 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Langote <amitlan@postgresql.org> writes:
> > Fix segfault from releasing locks in detached DSM segments
> > ...
> > Backpatch-through: 14
>
> I see no back-patch commits?
Push-script malfunction. Fixed.
--
Thanks, Amit Langote
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2026-01-16 05:47 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-01-16 04:26 pgsql: Fix segfault from releasing locks in detached DSM segments Amit Langote <amitlan@postgresql.org>
2026-01-16 04:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-01-16 05:47 ` Amit Langote <amitlangote09@gmail.com>
2026-01-16 05:45 pgsql: Fix segfault from releasing locks in detached DSM segments Amit Langote <amitlan@postgresql.org>
2026-01-16 05:46 pgsql: Fix segfault from releasing locks in detached DSM segments Amit Langote <amitlan@postgresql.org>
2026-01-16 05:46 pgsql: Fix segfault from releasing locks in detached DSM segments Amit Langote <amitlan@postgresql.org>
2026-01-16 05:46 pgsql: Fix segfault from releasing locks in detached DSM segments Amit Langote <amitlan@postgresql.org>
2026-01-16 05:46 pgsql: Fix segfault from releasing locks in detached DSM segments Amit Langote <amitlan@postgresql.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox