Re: postgresql-8.3.7 unexpected connection closures

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: a(dot)maclean(at)cas(dot)edu(dot)au
Cc: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, justin <justin(at)emproshunts(dot)com>, General <pgsql-general(at)postgresql(dot)org>
Subject: Re: postgresql-8.3.7 unexpected connection closures
Date: 2009-06-23 01:49:16
Message-ID: 19557.1245721756@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Andrew Maclean <andrew(dot)amaclean(at)gmail(dot)com> writes:
> Messages in the log are consistently of the form:
> 2009-06-23 08:28:26 EST WARNING: worker took too long to start; cancelled
> FATAL: could not reattach to shared memory (key=252, addr=023F0000): 487
> 2009-06-23 08:35:58 EST WARNING: worker took too long to start; cancelled
> FATAL: could not reattach to shared memory (key=252, addr=023F0000): 487

I suspect the causality is actually the other way around from what you
imply here: an autovac worker process fails to start (generating the
FATAL ... 487 message) and after awhile the autovac launcher figures out
that the worker died and issues the WARNING. It might be hard to tell
that since the launcher would probably try to launch another worker
immediately after realizing the previous one died. Looking at the
startup sequence to see which one appears first would be useful.

The "reattach to shared memory" problem is known, what we don't know is
exactly what causes it or how to fix it. As noted, we need some people
who can reproduce the problem consistently (none of the developers can)
to poke into it and find out what aspect of their systems causes it.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Arndt Lehmann 2009-06-23 02:07:48 Re: Trigger Function and backup
Previous Message Scott Marlowe 2009-06-23 01:44:55 Re: Replication