Mathieu De Zutter <math...@dezutter.org> writes:
> $ sudo ipcs -m
> ------ Shared Memory Segments --------
> key shmid owner perms bytes nattch status
> 0x0052e2c1 1081344 postgres 600 30384128 21
> 0x00000000 425985 postgres 600 18440 34
> 0x00000000 458754 postgres 600 16384 34
> 0x00000000 491523 postgres 600 768 34
> 0x00000000 524292 postgres 600 12 34
Hmm, I wonder what those last four are? Surely they are too small
to be Postgres shmem segments, but if they're something else like X11
segments then why do we only see ones belong to user postgres? I think
it's probably irrelevant to the problem, but just wondering ...
> Note that I stopped/started postgresql last night.
The evidence may be gone then. I still think that disconnected backends
are the most plausible explanation, but you might have killed everything
off.
As far as anyone knows, it's impossible to get into the
disconnected-backends state unless (a) you manually remove the
postmaster.pid file that provides the interlock against it, or
(b) you're trying to run multiple copies of Postgres on different
machines that're sharing an NFS or SAN mount of the same database files.
I assume you'd have mentioned it if you were trying (b), but I wonder
whether you have an init script that takes it on itself to remove the
postmaster.pid file? It's generally considered irresponsible for an
init script to do that, but I'm not sure every distro has gotten the word.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
