Thread: ERROR: could not attach to dynamic shared area
Hi all, in the logs of my database server, I found the following message: > ERROR: could not attach to dynamic shared area > LOG: background worker "parallel worker" (PID 51151) exited with exit code 1 What is the meaning of the error? The box is running Debian Buster, using the official PostgreSQL 13.2 deb's. The machinehas 384 GByte RAM, which, according to the Nagios logs, was /not/ filled completely (~1/3 free) when the message occurred,so I don't think its a system OOM condition. I did not observe any other effects (like data loss or similar). Any idea what might trigger such an error condition? Should I adjust the config to avoid them? How? Thanks in advance, Albrecht.
Attachment
Laurenz Albe <laurenz.albe@cybertec.at> writes: > On Wed, 2021-03-24 at 09:01 +0100, Albrecht Dreß wrote: >> in the logs of my database server, I found the following message: >>> ERROR: could not attach to dynamic shared area >>> LOG: background worker "parallel worker" (PID 51151) exited with exit code 1 > ... it could be a race condition: a parallel query finished rather fast, > but one of the parallel workers took long to start up, so when it tries to > attach to the dynamic shared memory segment used to exchange data between the > parallel processes, it realizes that everybody else has already left and > destroyed the memory segment. If the error only appeared in the log, and wasn't reported to the client, then this theory seems pretty plausible. regards, tom lane
Am 24.03.21 17:09 schrieb(en) Laurenz Albe: > > > ERROR: could not attach to dynamic shared area > > > LOG: background worker "parallel worker" (PID 51151) exited with exit code 1 > > Is that repeatable? No, it isn't. I'm running PGSql 13 since ~4 Months (cluster upgraded from v. 10), and updated to 13.2 ~four weeks ago. The error occurred exactly /once/. > If not, it could be a race condition: a parallel query finished rather fast, > but one of the parallel workers took long to start up, so when it tries to > attach to the dynamic shared memory segment used to exchange data between the > parallel processes, it realizes that everybody else has already left and > destroyed the memory segment. That makes sense! The triggering statement I found in the log performs a quite complex join, typically returning very fewrecords. And the calling application (using libpq) did *not* receive any error. > In the latter case, you can ignore the error. Good to know that! Thanks a lot for your fast help, Albrecht.