Re: postgresql-8.3.7 unexpected connection closures

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)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/
___________________________________________