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
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 |