MIME-Version: 1.0
From: =?UTF-8?B?QWxlxaEgWmVsZW7DvQ==?= <zeleny.ales@gmail.com>
Date: Sat, 21 Jun 2025 23:09:49 +0200
Message-ID: <CAODqTUaYHVKWFitXQvdhn0jrmVL60=bTp=eOAX2dR7x0ymZshQ@mail.gmail.com>
Subject: PostgreSQL 17.5 - could not map dynamic shared memory segment
To: "pgsql-generallists.postgresql.org" <pgsql-general@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000dd526d06381b669d"
Archived-At: <https://www.postgresql.org/message-id/CAODqTUaYHVKWFitXQvdhn0jrmVL60%3DbTp%3DeOAX2dR7x0ymZshQ%40mail.gmail.com>
Precedence: bulk

--000000000000dd526d06381b669d
Content-Type: text/plain; charset="UTF-8"

Hello,

After upgrading from (old good no longer supported Pg11) to PostgreSQL 17.5
via pg_dump & pg_restore vacuum started reporting errors:

ERROR:  could not map dynamic shared memory segment

Vacuumdb was invoked:

/usr/lib/postgresql/17/bin/vacuumdb -p 5433 -Fvaz -j 12 -v

The vacuum finished exit code was 0, but in PostgreSQL instance log files,
the errors above were logged.

Example error messages from the PostgreSQL log file:
2025-06-21 16:29:56.095 UTC [306130] ERROR:  could not map dynamic shared
memory segment
2025-06-21 16:29:56.095 UTC [306131] ERROR:  could not map dynamic shared
memory segment
2025-06-21 16:29:56.097 UTC [135978] LOG:  background worker "parallel
worker" (PID 306130) exited with exit code 1
2025-06-21 16:29:56.097 UTC [135978] LOG:  background worker "parallel
worker" (PID 306131) exited with exit code 1
2025-06-21 16:30:23.677 UTC [300930] postgres@fin LOG:  could not send data
to client: Broken pipe
2025-06-21 16:30:23.677 UTC [300930] postgres@fin CONTEXT:  while scanning
relation "core.cusip"
2025-06-21 16:30:23.677 UTC [300930] postgres@fin STATEMENT:  VACUUM
(SKIP_DATABASE_STATS, FREEZE, VERBOSE) core.cusip;
2025-06-21 16:30:23.677 UTC [300930] postgres@fin FATAL:  connection to
client lost
2025-06-21 16:30:23.677 UTC [300930] postgres@fin CONTEXT:  while scanning
relation "core.cusip"
2025-06-21 16:30:23.677 UTC [300930] postgres@fin STATEMENT:  VACUUM
(SKIP_DATABASE_STATS, FREEZE, VERBOSE) core.cusip;
2025-06-21 16:30:23.678 UTC [306190] ERROR:  could not map dynamic shared
memory segment
2025-06-21 16:30:23.680 UTC [135978] LOG:  background worker "parallel
worker" (PID 306190) exited with exit code 1

PostgreSQL version:
psql -d postgres -c "select version();"
                                                              version

-----------------------------------------------------------------------------------------------------------------------------------
 PostgreSQL 17.5 (Ubuntu 17.5-1.pgdg22.04+1) on x86_64-pc-linux-gnu,
compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
(1 row)

Configuration parameters:
listen_addresses = '*' # what IP address(es) to listen on;
port = 5432 # (change requires restart)
max_connections = 400 # (change requires restart)
unix_socket_directories = '/var/run/postgresql' # comma-separated list of
directories
tcp_keepalives_idle = 60 # TCP_KEEPIDLE, in seconds;
tcp_keepalives_interval = 5 # TCP_KEEPINTVL, in seconds;
tcp_keepalives_count = 3 # TCP_KEEPCNT;
tcp_user_timeout = 75s # TCP_USER_TIMEOUT, in milliseconds;
client_connection_check_interval = 75s # time between checks for client
shared_buffers = 22GB # min 128kB
huge_pages = on # on, off, or try
temp_buffers = 32MB # min 800kB
work_mem = 64MB # min 64kB
maintenance_work_mem = 2GB # min 64kB
dynamic_shared_memory_type = posix # the default is usually the first option
bgwriter_delay = 10ms # 10-10000ms between rounds
bgwriter_lru_maxpages = 1000 # max buffers written/round, 0 disables
bgwriter_lru_multiplier = 10.0 # 0-10.0 multiplier on buffers scanned/round
max_worker_processes = 24 # (change requires restart)
wal_level = logical # minimal, replica, or logical
wal_log_hints = on # also do full page writes of non-critical updates
checkpoint_timeout = 30min # range 30s-1d
checkpoint_completion_target = 0.8 # checkpoint target duration, 0.0 - 1.0
max_wal_size = 120GB
min_wal_size = 10GB
archive_timeout = 1800 # force a WAL file switch after this
max_wal_senders = 12 # max number of walsender processes
max_replication_slots = 12 # max number of replication slots
wal_sender_timeout = 600s # in milliseconds; 0 disables
track_commit_timestamp = on # collect timestamp of transaction commit
wal_receiver_timeout = 600s # time that receiver waits for
jit = off # allow JIT compilation
log_min_duration_statement = 1000 # -1 is disabled, 0 logs all statements
log_autovacuum_min_duration = 0 # log autovacuum activity;
log_checkpoints = on
track_activity_query_size = 32768 # (change requires restart)
track_io_timing = on
track_functions = all # none, pl, all
idle_in_transaction_session_timeout = 1200000 # in milliseconds, 0 is
disabled
shared_preload_libraries =
'pg_stat_statements,pg_stat_kcache,pg_qualstats,pg_partman_bgw,pg_cron,pg_prewarm'
# (change requires restart)
max_locks_per_transaction = 128 # min 10


OS: Ubuntu 22.04.5 LTS, 16vCPUs, ~123 GB RAM
PostgreSQL apt package: postgresql-17/jammy-pgdg,now 17.5-1.pgdg22.04+1
amd64 [installed]

Memory:
grep -e Mem -e Huge /proc/meminfo
MemTotal:       129804320 kB
MemFree:         2127576 kB
MemAvailable:   100695068 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
FileHugePages:         0 kB
HugePages_Total:   12672
HugePages_Free:    10908
HugePages_Rsvd:     9818
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:        25952256 kB

It also happened during the application load test, but I've accidentally
copied a wrong log file, and now the server is decommissioned, so I have no
details on application queries reporting the exact same message, but it
seemed to be related to parallel queries as well if I remember it properly.

The application benefits from parallel queries, so despite the first
temptation to disable parallel queries (based on log entries correlation
only, but is that the root cause?) I did not want to disable parallel
queries, if there is another workaround/solution/fix available.

Thanks for any hints on how to provide more information if needed, as well
as for fix/workaround advice.

Kind regards Ales Zeleny

--000000000000dd526d06381b669d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello,</div><div><br></div><div>After upgrading from =
(old good no longer supported Pg11) to PostgreSQL 17.5 via pg_dump &amp; pg=
_restore vacuum started reporting errors:</div><div><br></div><div>ERROR: =
=C2=A0could not map dynamic shared memory segment</div><div><br></div><div>=
Vacuumdb was invoked:</div><div><br></div><div>/usr/lib/postgresql/17/bin/v=
acuumdb -p 5433 -Fvaz -j 12 -v</div><div><br></div><div>The vacuum finished=
 exit code was 0, but in PostgreSQL instance log files, the errors above we=
re logged.</div><div><br></div><div>Example error messages from the Postgre=
SQL log file:</div><div>2025-06-21 16:29:56.095 UTC [306130] ERROR: =C2=A0c=
ould not map dynamic shared memory segment<br>2025-06-21 16:29:56.095 UTC [=
306131] ERROR: =C2=A0could not map dynamic shared memory segment<br>2025-06=
-21 16:29:56.097 UTC [135978] LOG: =C2=A0background worker &quot;parallel w=
orker&quot; (PID 306130) exited with exit code 1<br>2025-06-21 16:29:56.097=
 UTC [135978] LOG: =C2=A0background worker &quot;parallel worker&quot; (PID=
 306131) exited with exit code 1<br>2025-06-21 16:30:23.677 UTC [300930] po=
stgres@fin LOG: =C2=A0could not send data to client: Broken pipe<br>2025-06=
-21 16:30:23.677 UTC [300930] postgres@fin CONTEXT: =C2=A0while scanning re=
lation &quot;core.cusip&quot;<br>2025-06-21 16:30:23.677 UTC [300930] postg=
res@fin STATEMENT: =C2=A0VACUUM (SKIP_DATABASE_STATS, FREEZE, VERBOSE) core=
.cusip;<br>2025-06-21 16:30:23.677 UTC [300930] postgres@fin FATAL: =C2=A0c=
onnection to client lost<br>2025-06-21 16:30:23.677 UTC [300930] postgres@f=
in CONTEXT: =C2=A0while scanning relation &quot;core.cusip&quot;<br>2025-06=
-21 16:30:23.677 UTC [300930] postgres@fin STATEMENT: =C2=A0VACUUM (SKIP_DA=
TABASE_STATS, FREEZE, VERBOSE) core.cusip;<br>2025-06-21 16:30:23.678 UTC [=
306190] ERROR: =C2=A0could not map dynamic shared memory segment<br>2025-06=
-21 16:30:23.680 UTC [135978] LOG: =C2=A0background worker &quot;parallel w=
orker&quot; (PID 306190) exited with exit code 1</div><div><br></div><div>P=
ostgreSQL version:</div><div>psql -d postgres -c &quot;select version();&qu=
ot;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 version =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0<br>-----------------------------------------------------------------=
------------------------------------------------------------------<br>=C2=
=A0PostgreSQL 17.5 (Ubuntu 17.5-1.pgdg22.04+1) on x86_64-pc-linux-gnu, comp=
iled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit<br>(1 row)</div><=
div><br></div><div>Configuration parameters:</div><div>listen_addresses =3D=
 &#39;*&#39;		# what IP address(es) to listen on;<br>port =3D 5432				# (ch=
ange requires restart)<br>max_connections =3D 400			# (change requires rest=
art)<br>unix_socket_directories =3D &#39;/var/run/postgresql&#39; # comma-s=
eparated list of directories<br>tcp_keepalives_idle =3D 60		# TCP_KEEPIDLE,=
 in seconds;<br>tcp_keepalives_interval =3D 5		# TCP_KEEPINTVL, in seconds;=
<br>tcp_keepalives_count =3D 3		# TCP_KEEPCNT;<br>tcp_user_timeout =3D 75s	=
		# TCP_USER_TIMEOUT, in milliseconds;<br>client_connection_check_interval =
=3D 75s	# time between checks for client<br>shared_buffers =3D 22GB			# min=
 128kB<br>huge_pages =3D on			# on, off, or try<br>temp_buffers =3D 32MB			=
# min 800kB<br>work_mem =3D 64MB				# min 64kB<br>maintenance_work_mem =3D =
2GB		# min 64kB<br>dynamic_shared_memory_type =3D posix	# the default is us=
ually the first option<br>bgwriter_delay =3D 10ms			# 10-10000ms between ro=
unds<br>bgwriter_lru_maxpages =3D 1000		# max buffers written/round, 0 disa=
bles<br>bgwriter_lru_multiplier =3D 10.0		# 0-10.0 multiplier on buffers sc=
anned/round<br>max_worker_processes =3D 24		# (change requires restart)<br>=
wal_level =3D logical			# minimal, replica, or logical<br>wal_log_hints =3D=
 on			# also do full page writes of non-critical updates<br>checkpoint_time=
out =3D 30min		# range 30s-1d<br>checkpoint_completion_target =3D 0.8	# che=
ckpoint target duration, 0.0 - 1.0<br>max_wal_size =3D 120GB<br>min_wal_siz=
e =3D 10GB<br>archive_timeout =3D 1800		# force a WAL file switch after thi=
s<br>max_wal_senders =3D 12		# max number of walsender processes<br>max_rep=
lication_slots =3D 12	# max number of replication slots<br>wal_sender_timeo=
ut =3D 600s	# in milliseconds; 0 disables<br>track_commit_timestamp =3D on	=
# collect timestamp of transaction commit<br>wal_receiver_timeout =3D 600s	=
	# time that receiver waits for<br>jit =3D off				# allow JIT compilation<b=
r>log_min_duration_statement =3D 1000	# -1 is disabled, 0 logs all statemen=
ts<br>log_autovacuum_min_duration =3D 0	# log autovacuum activity;<br>log_c=
heckpoints =3D on<br>track_activity_query_size =3D 32768	# (change requires=
 restart)<br>track_io_timing =3D on<br>track_functions =3D all			# none, pl=
, all<br>idle_in_transaction_session_timeout =3D 1200000	# in milliseconds,=
 0 is disabled<br>shared_preload_libraries =3D &#39;pg_stat_statements,pg_s=
tat_kcache,pg_qualstats,pg_partman_bgw,pg_cron,pg_prewarm&#39;		# (change r=
equires restart)<br>max_locks_per_transaction =3D 128		# min 10</div><div><=
br></div><div><br></div><div><div>OS:=C2=A0Ubuntu 22.04.5 LTS, 16vCPUs, ~12=
3 GB RAM</div><div></div><div>PostgreSQL apt package:=C2=A0postgresql-17/ja=
mmy-pgdg,now 17.5-1.pgdg22.04+1 amd64 [installed]</div><div></div></div><di=
v><br></div><div>Memory:</div><div>grep -e Mem -e Huge /proc/meminfo <br>Me=
mTotal: =C2=A0 =C2=A0 =C2=A0 129804320 kB<br>MemFree: =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 2127576 kB<br>MemAvailable: =C2=A0 100695068 kB<br>AnonHugePages: =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 0 kB<br>ShmemHugePages: =C2=A0 =C2=A0 =C2=A0 =
=C2=A00 kB<br>FileHugePages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 kB<br>HugePages_=
Total: =C2=A0 12672<br>HugePages_Free: =C2=A0 =C2=A010908<br>HugePages_Rsvd=
: =C2=A0 =C2=A0 9818<br>HugePages_Surp: =C2=A0 =C2=A0 =C2=A0 =C2=A00<br>Hug=
epagesize: =C2=A0 =C2=A0 =C2=A0 2048 kB<br>Hugetlb: =C2=A0 =C2=A0 =C2=A0 =
=C2=A025952256 kB</div><div></div><br><div>It also happened during the appl=
ication load test, but I&#39;ve accidentally copied a wrong log file, and n=
ow the server is decommissioned, so I have no details on application querie=
s reporting the exact same message, but it seemed to be related to parallel=
 queries as well if I remember it properly.</div><div><br></div><div>The ap=
plication benefits from parallel queries, so despite the first temptation t=
o disable parallel queries (based on log entries correlation only, but is t=
hat the root cause?) I did not want to disable parallel queries, if there i=
s another workaround/solution/fix available.</div><div><br></div><div>Thank=
s for any hints on how to provide more information if needed, as well as fo=
r fix/workaround advice.</div><div><br></div><div>Kind regards Ales Zeleny<=
/div><div><br></div></div>

--000000000000dd526d06381b669d--