public inbox for [email protected]  
help / color / mirror / Atom feed
From: Reshmithaa <[email protected]>
To: Tomas <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Crash related to Shared Memory
Date: Mon, 16 Feb 2026 14:47:29 +0530
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>

Hi,

> The second trace

> unfortunately does not show what happened to PID 2037344 before it

> crashes, which would be very interesting to know. Was it an OOM too?








Kindly find the attachment below.





Regards,


Reshmithaa B






From: Reshmithaa <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Date: Mon, 16 Feb 2026 14:12:25 +0530
Subject: Re: Crash related to Shared Memory



Hi Tomas Vondra,



> What extensions are you using? Especially extensions third-party

> extensions?

We are working on our own columnar extension and have modified the PostgreSQL source code to enable pg stats for foreign tables and to support autoanalyze and autovacuum on foreign tables.

From PostgreSQL 15 onward, statistics were moved to shared memory. We started observing this issue in production after upgrading from PostgreSQL 14 to PostgreSQL 17.2 / 17.7.

Could this dsa issue be related to pg stats?



> The second trace

> unfortunately does not show what happened to PID 2037344 before it

> crashes, which would be very interesting to know. Was it an OOM too?

The process with PID 2037344 did not terminate due to an OOM intead ended with segfalut.

Regards

Reshmithaa B








From: Tomas Vondra < mailto:[email protected] >
To: "Reshmithaa"< mailto:[email protected] >, "pgsql-hackers"< mailto:[email protected] >
Date: Mon, 16 Feb 2026 03:34:53 +0530
Subject: Re: Crash related to Shared Memory










Hi, 






On 2/15/26 09:53, Reshmithaa wrote: 
> Hi, 
> 
> We have developed a PostgreSQL extension and are currently encountering 
> intermittent crashes related to shared memory on PostgreSQL 17.7. The 
> issue does not occur everytime, and we have not been able to reliably 
> reproduce it in our local environment. We have attached the relevant pg 
> logs and backtraces below for reference. 
> 
> We also noticed a recent commit addressing a DSM-related issue: 
> 
> https://git.postgresql.org/gitweb/?  
> p=postgresql.git;a=commitdiff;h=1d0fc2499 < https://git.postgresql.org/  
> gitweb/?p=postgresql.git;a=commitdiff;h=1d0fc2499> 
> 
> Could you please confirm whether this change can resolve the type of 
> crash we are encountering? 
> 
 
Maybe, but it's hard to say based on the logs you provided. 
 
In the commit message you linked, Robert speculated this should not be 
happening in core Postgres, but that maybe extensions could trip over 
this. What extensions are you using? Especially extensions third-party 
extensions? 
 
It's interesting both traces end with a segfault, but in both cases 
there are "strange" errors immediately before that. In particular the 
first trace shows 
 
[568804]:ERROR:  53200: out of memory 
[568804]:DETAIL:  Failed while allocating entry 2/17266/55068384. 
[568804]:LOCATION:  pgstat_get_entry_ref, pgstat_shmem.c:510 
[568804]:STATEMENT:   ANALYZE tab2_temp 
 
For the process that then crashes with a segfault. The second trace 
unfortunately does not show what happened to PID 2037344 before it 
crashes, which would be very interesting to know. Was it an OOM too? 
 
But there are a couple other suspicious errors from other PIDs, like 
 
[2136038]:ERROR:  XX000: dsa_area could not attach to a segment that has 
been freed 
[2136038]:LOCATION:  get_segment_by_index, dsa.c:1781 
 
I don't think this should be happening in core code, at least I don't 
recall seeing anything like that recently. 
 
 
I wonder if the cleanup after OOM could lead to the crash because the 
error cleanup destroys the short-lived context, in a way Robert did not 
envision in the commit message. But I haven't tried and it's just a 
speculation. 
 
FWIW even if the commit (and upgrading to 17.8) fixes the crash, I don't 
think that'll fix the other errors shown in the traces. You should 
probably look into that. 
 
 
regards 
 
-- 
Tomas Vondra
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:LOG:  00000: PRIMITIVE NOT USED: map_pg_backend_pid
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:LOCATION:  LogPrimFunctions, primitiveMgr.cpp:39
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:STATEMENT:  select pg_backend_pid()
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:LOG:  00000: PRIMITIVE NOT USED: map_pg_backend_pid
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:LOCATION:  LogPrimFunctions, primitiveMgr.cpp:39
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:STATEMENT:  select pg_backend_pid()
2026-01-22 00:57:51 GMT::@:[2061697]:LOG:  00000: Running single-threaded autovacuum for table 261184335 in database 17266
2026-01-22 00:57:51 GMT::@:[2061697]:LOCATION:  operator(), cstore_vacuum.cpp:267
2026-01-22 00:57:51 GMT::@:[2061905]:LOG:  00000: Running single-threaded autovacuum for table 193649 in database 17266
2026-01-22 00:57:51 GMT::@:[2061905]:LOCATION:  operator(), cstore_vacuum.cpp:267
2026-01-22 00:57:51 GMT:<ip>(34946)[2126874]:LOG:  00000: PRIMITIVE NOT USED: map_pg_backend_pid
2026-01-22 00:57:51 GMT:<ip>(34946)[2126874]:LOCATION:  LogPrimFunctions, primitiveMgr.cpp:39
2026-01-22 00:57:51 GMT:<ip>(34946)[2126874]:STATEMENT:  select pg_backend_pid(),'value1','value2'  
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:LOG:  00000: PRIMITIVE NOT USED: map_pg_backend_pid
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:LOCATION:  LogPrimFunctions, primitiveMgr.cpp:39
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:STATEMENT:  select pg_backend_pid(),'value1','value2'
2026-01-22 00:57:51 GMT::@:[2061697]:LOG:  00000: Running single-threaded autovacuum for table 261218586 in database 17266
2026-01-22 00:57:51 GMT::@:[2061697]:LOCATION:  operator(), cstore_vacuum.cpp:267
2026-01-22 00:57:51 GMT::@:[2061697]:LOG:  00000: Running single-threaded autovacuum for table 261222200 in database 17266
2026-01-22 00:57:51 GMT::@:[2061697]:LOCATION:  operator(), cstore_vacuum.cpp:267
2026-01-22 00:57:51 GMT::@:[2136038]:ERROR:  XX000: dsa_area could not attach to a segment that has been freed
2026-01-22 00:57:51 GMT::@:[2136038]:LOCATION:  get_segment_by_index, dsa.c:1781
2026-01-22 00:57:51 GMT::@:[2136037]:ERROR:  XX000: dsa_area could not attach to a segment that has been freed
2026-01-22 00:57:51 GMT::@:[2136037]:LOCATION:  get_segment_by_index, dsa.c:1781
2026-01-22 00:57:51 GMT:<ip>(46398)[2018946]:ERROR:  XX000: dsa_area could not attach to a segment that has been freed
2026-01-22 00:57:51 GMT:<ip>(46398)[2018946]:CONTEXT:  parallel worker
2026-01-22 00:57:51 GMT:<ip>(46398)[2018946]:LOCATION:  get_segment_by_index, dsa.c:1781
2026-01-22 00:57:51 GMT:<ip>(46398)[2018946]:STATEMENT:  select sum(enumrowcount)::bigint from srlaudit where dbid = <id> and table_id != <value>
2026-01-22 00:57:51 GMT::@:[875575]:LOG:  00000: background worker "parallel worker" (PID 2136037) exited with exit code 1
2026-01-22 00:57:51 GMT::@:[875575]:LOCATION:  LogChildExit, postmaster.c:3086
2026-01-22 00:57:51 GMT::@:[875575]:LOG:  00000: background worker "parallel worker" (PID 2136038) exited with exit code 1
2026-01-22 00:57:51 GMT::@:[875575]:LOCATION:  LogChildExit, postmaster.c:3086
2026-01-22 00:57:51 GMT::@:[2061697]:LOG:  00000: Running single-threaded autovacuum for table 129145779 in database 17266
2026-01-22 00:57:51 GMT::@:[2061697]:LOCATION:  operator(), cstore_vacuum.cpp:267
2026-01-22 00:57:51 GMT::@:[875575]:LOG:  00000: server process (PID 2037344) was terminated by signal 11: Segmentation fault
2026-01-22 00:57:51 GMT::@:[875575]:DETAIL:  Failed process was running: INSERT INTO tab (c1, c2, c3, c3, c4, c5, c6, c7, c8, c9, c10, c11, c12, c13)...
2026-01-22 00:57:51 GMT::@:[875575]:LOCATION:  LogChildExit, postmaster.c:3108
2026-01-22 00:57:51 GMT::@:[875575]:LOG:  00000: terminating any other active server processes
2026-01-22 00:57:51 GMT::@:[875575]:LOCATION:  HandleChildCrash, postmaster.c:2897
2026-01-22 00:57:52 GMT:172.25.249.16(59040):sas@reports:[2136093]:FATAL:  57P03: the database system is in recovery mode
2026-01-22 00:57:52 GMT:172.25.249.16(59040):sas@reports:[2136093]:LOCATION:  BackendInitialize, backend_startup.c:299
2026-01-22 00:57:52 GMT:172.25.249.16(59054):sas@reports:[2136094]:FATAL:  57P03: the database system is in recovery mode



Attachments:

  [text/plain] Trace2.txt (4.2K, ../[email protected]/3-Trace2.txt)
  download | inline:
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:LOG:  00000: PRIMITIVE NOT USED: map_pg_backend_pid
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:LOCATION:  LogPrimFunctions, primitiveMgr.cpp:39
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:STATEMENT:  select pg_backend_pid()
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:LOG:  00000: PRIMITIVE NOT USED: map_pg_backend_pid
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:LOCATION:  LogPrimFunctions, primitiveMgr.cpp:39
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:STATEMENT:  select pg_backend_pid()
2026-01-22 00:57:51 GMT::@:[2061697]:LOG:  00000: Running single-threaded autovacuum for table 261184335 in database 17266
2026-01-22 00:57:51 GMT::@:[2061697]:LOCATION:  operator(), cstore_vacuum.cpp:267
2026-01-22 00:57:51 GMT::@:[2061905]:LOG:  00000: Running single-threaded autovacuum for table 193649 in database 17266
2026-01-22 00:57:51 GMT::@:[2061905]:LOCATION:  operator(), cstore_vacuum.cpp:267
2026-01-22 00:57:51 GMT:<ip>(34946)[2126874]:LOG:  00000: PRIMITIVE NOT USED: map_pg_backend_pid
2026-01-22 00:57:51 GMT:<ip>(34946)[2126874]:LOCATION:  LogPrimFunctions, primitiveMgr.cpp:39
2026-01-22 00:57:51 GMT:<ip>(34946)[2126874]:STATEMENT:  select pg_backend_pid(),'value1','value2'  
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:LOG:  00000: PRIMITIVE NOT USED: map_pg_backend_pid
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:LOCATION:  LogPrimFunctions, primitiveMgr.cpp:39
2026-01-22 00:57:51 GMT:<ip>(33028)[2037344]:STATEMENT:  select pg_backend_pid(),'value1','value2'
2026-01-22 00:57:51 GMT::@:[2061697]:LOG:  00000: Running single-threaded autovacuum for table 261218586 in database 17266
2026-01-22 00:57:51 GMT::@:[2061697]:LOCATION:  operator(), cstore_vacuum.cpp:267
2026-01-22 00:57:51 GMT::@:[2061697]:LOG:  00000: Running single-threaded autovacuum for table 261222200 in database 17266
2026-01-22 00:57:51 GMT::@:[2061697]:LOCATION:  operator(), cstore_vacuum.cpp:267
2026-01-22 00:57:51 GMT::@:[2136038]:ERROR:  XX000: dsa_area could not attach to a segment that has been freed
2026-01-22 00:57:51 GMT::@:[2136038]:LOCATION:  get_segment_by_index, dsa.c:1781
2026-01-22 00:57:51 GMT::@:[2136037]:ERROR:  XX000: dsa_area could not attach to a segment that has been freed
2026-01-22 00:57:51 GMT::@:[2136037]:LOCATION:  get_segment_by_index, dsa.c:1781
2026-01-22 00:57:51 GMT:<ip>(46398)[2018946]:ERROR:  XX000: dsa_area could not attach to a segment that has been freed
2026-01-22 00:57:51 GMT:<ip>(46398)[2018946]:CONTEXT:  parallel worker
2026-01-22 00:57:51 GMT:<ip>(46398)[2018946]:LOCATION:  get_segment_by_index, dsa.c:1781
2026-01-22 00:57:51 GMT:<ip>(46398)[2018946]:STATEMENT:  select sum(enumrowcount)::bigint from srlaudit where dbid = <id> and table_id != <value>
2026-01-22 00:57:51 GMT::@:[875575]:LOG:  00000: background worker "parallel worker" (PID 2136037) exited with exit code 1
2026-01-22 00:57:51 GMT::@:[875575]:LOCATION:  LogChildExit, postmaster.c:3086
2026-01-22 00:57:51 GMT::@:[875575]:LOG:  00000: background worker "parallel worker" (PID 2136038) exited with exit code 1
2026-01-22 00:57:51 GMT::@:[875575]:LOCATION:  LogChildExit, postmaster.c:3086
2026-01-22 00:57:51 GMT::@:[2061697]:LOG:  00000: Running single-threaded autovacuum for table 129145779 in database 17266
2026-01-22 00:57:51 GMT::@:[2061697]:LOCATION:  operator(), cstore_vacuum.cpp:267
2026-01-22 00:57:51 GMT::@:[875575]:LOG:  00000: server process (PID 2037344) was terminated by signal 11: Segmentation fault
2026-01-22 00:57:51 GMT::@:[875575]:DETAIL:  Failed process was running: INSERT INTO tab (c1, c2, c3, c3, c4, c5, c6, c7, c8, c9, c10, c11, c12, c13)...
2026-01-22 00:57:51 GMT::@:[875575]:LOCATION:  LogChildExit, postmaster.c:3108
2026-01-22 00:57:51 GMT::@:[875575]:LOG:  00000: terminating any other active server processes
2026-01-22 00:57:51 GMT::@:[875575]:LOCATION:  HandleChildCrash, postmaster.c:2897
2026-01-22 00:57:52 GMT:172.25.249.16(59040):sas@reports:[2136093]:FATAL:  57P03: the database system is in recovery mode
2026-01-22 00:57:52 GMT:172.25.249.16(59040):sas@reports:[2136093]:LOCATION:  BackendInitialize, backend_startup.c:299
2026-01-22 00:57:52 GMT:172.25.249.16(59054):sas@reports:[2136094]:FATAL:  57P03: the database system is in recovery mode


view thread (8+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Crash related to Shared Memory
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox