Thanks for this. I can't take the machines out of service at present,
but when I can, I'll look into shutting down services and seeing what
happens.
Andrew
On Tue, Jun 23, 2009 at 11:49 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Andrew Maclean <andrew.amaclean@gmail.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
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
--
___________________________________________
Andrew J. P. Maclean
Centre for Autonomous Systems
The Rose Street Building J04
The University of Sydney 2006 NSW
AUSTRALIA
Ph: +61 2 9351 3283
Fax: +61 2 9351 7474
URL: http://www.acfr.usyd.edu.au/
___________________________________________