Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vrvXV-00DJim-1p for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Feb 2026 10:09:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vrvWV-001Gcy-19 for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Feb 2026 10:08:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vrvUV-0015uH-32 for pgsql-hackers@lists.postgresql.org; Mon, 16 Feb 2026 10:06:08 +0000 Received: from sender2-pp-e104.zoho.in ([169.148.134.104]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vrujh-00000000rNC-0LJP for pgsql-hackers@postgresql.org; Mon, 16 Feb 2026 09:17:47 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1771233452; cv=none; d=zohomail.in; s=zohoarc; b=G4A2zEMB7H7fY1/8NrfEZ1tn97spvmtYNh3R+10WXdtwLcYZuofUXk2UdbR6onuaST9ysujVNUKLrmeEHR8YQZURpgci9jFxNKNNKoWC4gKHGFvME+BBggwpoZdISO24er31utUnf8FkMm8+u7xcSxVAMPozkocMHg825bnsk7M= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.in; s=zohoarc; t=1771233452; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=FS750HVIsUaKaUXqMJWhTYjQXpGvtjtxYwPiburXDJY=; b=Rfgj/Di2cxk1j5/Wx32Kz7MWXrAeoap62enR92GqNBf0ImpqaA1WOlFm492cjPBXOh4tO5hS4QWPiSdx4fcl+0YC6Rb4uFHZw36Z0ZvHK3g6MsLRCP9JzWY/YvNabJG04BP9DnEfYD2lX1PzzVykeLEvRKuObTT8dYpAQ03h3Ys= ARC-Authentication-Results: i=1; mx.zohomail.in; dkim=pass header.i=zohocorp.com; spf=pass smtp.mailfrom=reshmithaa.b@zohocorp.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1771233452; s=admin1; d=zohocorp.com; i=reshmithaa.b@zohocorp.com; h=Date:Date:From:From:To:To:Cc:Cc:Message-Id:Message-Id:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Reply-To; bh=FS750HVIsUaKaUXqMJWhTYjQXpGvtjtxYwPiburXDJY=; b=RWWcrCysWKTtvKk1UfjTA+/JkRuHqsDZ22tUGTZmMCAgC+1ktSdGM6s+Gzy20IVY BmgEJpfUDq1lAEzgEICRgkZIZlauPr+wr5gdg6jC83hUbW5qry9+4mLPetXjo54OazP y2dTmT1o6pZeLMyk3NsSCRSJu07UWgwHiUItOqZg= Received: from mail.zoho.in by mx.zoho.in with SMTP id 1771233449865118.42298949931933; Mon, 16 Feb 2026 14:47:29 +0530 (IST) Date: Mon, 16 Feb 2026 14:47:29 +0530 From: Reshmithaa To: "Tomas" Cc: "pgsql-hackers" Message-Id: <19c65bd9773.26e5e71b69048.4962060727905649666@zohocorp.com> In-Reply-To: <19c659d7b36.2b06478976593.2792647703134538263@zohocorp.com> References: <19c6080f721.5fb020da63611.6613570086464859270@zohocorp.com> <19c659d7b36.2b06478976593.2792647703134538263@zohocorp.com> Subject: Re: Crash related to Shared Memory MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_242938_1651562962.1771233449843" Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Zoho-Virus-Status: 1 X-Zoho-AV-Stamp: zmail-av-0.1.0.1.4.3/271.175.32 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_242938_1651562962.1771233449843 Content-Type: multipart/alternative; boundary="----=_Part_242939_2035794151.1771233449843" ------=_Part_242939_2035794151.1771233449843 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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 To: Cc: 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:tomas@vondra.me > To: "Reshmithaa"< mailto:reshmithaa.b@zohocorp.com >, "pgsql-hackers"< mailto:pgsql-hackers@postgresql.org > 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 ------=_Part_242939_2035794151.1771233449843 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
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 to= o?

Kindly find= the attachment below.


Reg= ards,
Reshmithaa B
From: Reshmithaa <reshmithaa.b@zohocorp= .com>
To: <tomas@vondra.me>
Cc: <pgsql-hackers@postgresql= .org>
Date: Mon, 16 Feb 2026 14:12:25 +0530
Subject: Re: Crash rel= ated to Shared Memory

Hi Tomas V= ondra,

> What extensions are you using? Espec= ially extensions third-party

> extensions?

We are wo= rking 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, statisti= cs were moved to shared memory. We started observing this issue in producti= on 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 PI= D 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
Reshmit= haa B


<= div class=3D"x_662287674x_2141228643zmail_extra">

From: Tomas Vondra <tomas@vondra.me>
To: "Reshmithaa"<= reshmithaa.b= @zohocorp.com>, "pgsql-hackers"<pgsql-hackers@postgresql.org>
Da= te: 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 encount= ering
> intermittent crashes related to shared memory on PostgreSQL = 17.7. The
> issue does not occur everytime, and we have not been abl= e to reliably
> reproduce it in our local environment. We have attac= hed the relevant pg
> logs and backtraces below for reference.
&= gt;
> We also noticed a recent commit addressing a DSM-related issue= :
>
> https://git.postgresql.org/gitweb/?
> p=3Dpostgresql= .git;a=3Dcommitdiff;h=3D1d0fc2499 <https://git.postgresql.org/
> gitweb/?p=3Dp= ostgresql.git;a=3Dcommitdiff;h=3D1d0fc2499>
>
> Could you = please confirm whether this change can resolve the type of
> crash w= e are encountering?
>

Maybe, but it's hard to say based on = the logs you provided.

In the commit message you linked, Robert sp= eculated this should not be
happening in core Postgres, but that maybe = extensions could trip over
this. What extensions are you using? Especia= lly extensions third-party
extensions?

It's interesting both t= races 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 al= locating entry 2/17266/55068384.
[568804]:LOCATION: pgstat_get_entry_r= ef, pgstat_shmem.c:510
[568804]:STATEMENT: ANALYZE tab2_temp
For the process that then crashes with a segfault. The second trace
un= fortunately does not show what happened to PID 2037344 before it
crashe= s, 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 th= e cleanup after OOM could lead to the crash because the
error cleanup d= estroys the short-lived context, in a way Robert did not
envision in th= e 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 <= br>probably look into that.


regards

--
Tomas Von= dra



<= /body> ------=_Part_242939_2035794151.1771233449843-- ------=_Part_242938_1651562962.1771233449843 Content-Type: text/plain; charset=us-ascii; name=Trace2.txt Content-Transfer-Encoding: 7bit X-ZM_AttachId: 139905262498430640 Content-Disposition: attachment; filename=Trace2.txt 2026-01-22 00:57:51 GMT:(33028)[2037344]:LOG: 00000: PRIMITIVE NOT USED: map_pg_backend_pid 2026-01-22 00:57:51 GMT:(33028)[2037344]:LOCATION: LogPrimFunctions, primitiveMgr.cpp:39 2026-01-22 00:57:51 GMT:(33028)[2037344]:STATEMENT: select pg_backend_pid() 2026-01-22 00:57:51 GMT:(33028)[2037344]:LOG: 00000: PRIMITIVE NOT USED: map_pg_backend_pid 2026-01-22 00:57:51 GMT:(33028)[2037344]:LOCATION: LogPrimFunctions, primitiveMgr.cpp:39 2026-01-22 00:57:51 GMT:(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:(34946)[2126874]:LOG: 00000: PRIMITIVE NOT USED: map_pg_backend_pid 2026-01-22 00:57:51 GMT:(34946)[2126874]:LOCATION: LogPrimFunctions, primitiveMgr.cpp:39 2026-01-22 00:57:51 GMT:(34946)[2126874]:STATEMENT: select pg_backend_pid(),'value1','value2' 2026-01-22 00:57:51 GMT:(33028)[2037344]:LOG: 00000: PRIMITIVE NOT USED: map_pg_backend_pid 2026-01-22 00:57:51 GMT:(33028)[2037344]:LOCATION: LogPrimFunctions, primitiveMgr.cpp:39 2026-01-22 00:57:51 GMT:(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:(46398)[2018946]:ERROR: XX000: dsa_area could not attach to a segment that has been freed 2026-01-22 00:57:51 GMT:(46398)[2018946]:CONTEXT: parallel worker 2026-01-22 00:57:51 GMT:(46398)[2018946]:LOCATION: get_segment_by_index, dsa.c:1781 2026-01-22 00:57:51 GMT:(46398)[2018946]:STATEMENT: select sum(enumrowcount)::bigint from srlaudit where dbid = and table_id != 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 ------=_Part_242938_1651562962.1771233449843--