Thread: ERROR: could not attach to dynamic shared area

ERROR: could not attach to dynamic shared area

From
Albrecht Dreß
Date:
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

Re: ERROR: could not attach to dynamic shared area

From
Tom Lane
Date:
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



Re: ERROR: could not attach to dynamic shared area

From
Albrecht Dreß
Date:
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.
Attachment