"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
>> But is there any particular reason for database to do such kind of
>> behavior.
>> DEBUG: pq_recvbuf: unexpected EOF on client connection
>> DEBUG: pq_recvbuf: unexpected EOF on client connection
>> DEBUG: pq_recvbuf: unexpected EOF on client connection
>> DEBUG: pq_recvbuf: unexpected EOF on client connection
>> DEBUG: database system was interrupted at 2003-05-03 04:17:19 SGT
>> DEBUG: checkpoint record is at 3/85EA18B0
> You've got high system load, inability for processes to claim more memory and
> errors about programs exiting at unexpected times.
What strikes me about the above trace is that we see "database system
was interrupted" without any prior failure. That says to me that
something killed the postmaster itself --- if a database child process
died, the postmaster would have logged the fact.
That leaves me with two questions: what killed the postmaster, and what
restarted it?
If Nigel's guess is right that the system is under heavy memory
pressure, and this is a Linux box, then the kernel itself might have
kill -9'd the postmaster to try to get out of a memory shortage.
I can't think of very many other theories (though I do recall at
least one self-inflicted problem, from someone whose "maintenance
script" kill -9'd the postmaster for random reasons...)
I'd also like to know whether the system is configured to auto-restart
the postmaster, and if so how, and does it do any mucking about (like
removing lockfiles) while it's doing so?
regards, tom lane
