On Thu, Jan 30, 2020 at 12:26 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Wed, Jan 29, 2020 at 11:24 PM Julian Backes <julianbackes@gmail.com> wrote:
> > we only had the "too many shared too many dynamic shared memory segments" error but no segmentation faults. The
errorstarted occurring after upgrading from postgres 10 to postgres 12 (server has 24 cores / 48 threads, i.e. many
parallelworkers). The error itself was not that much of a problem but /dev/shm started filling up with orphaned files
whichprobably (?) had not been cleaned up by postgres after the parallel workers died. In consequence, after some time,
/dev/shmwas full and everything crashed.
>
> Oh, thanks for the report. I think see what was happening there, and
> it's a third independent problem. The code in dsm_create() does
> DSM_OP_DESTROY (ie cleans up) in the DSM_CREATE_NULL_IF_MAXSEGMENTS
> case, but in the case where you see "ERROR: too many dynamic shared
> memory segments" it completely fails to clean up after itself. I can
> reproduce that here. That's a terrible bug, and has been sitting in
> the tree for 5 years.
I committed a fix for that. It'll be in the new releases that due out
in a couple of weeks.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=93745f1e019543fe7b742d0c5e971aad8d08fd56
> > Unfortunately, the only "solution" we found so far was to increase max connections from 100 to 1000. After that
(about2 months ago I think), the error had gone.
>
> I'll take that as a vote for increasing the number of slots.
I committed something to do this for 13 (due out end of year), but I'm
not game to back-patch it to the release branches.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=d061ea21fc1cc1c657bb5c742f5c4a1564e82ee2