| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Constantin Teodorescu <teo(at)flex(dot)ro> |
| Cc: | "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: [HACKERS] postgres (zombie) |
| Date: | 1999-01-25 15:37:11 |
| Message-ID: | 19058.917278631@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Constantin Teodorescu <teo(at)flex(dot)ro> writes:
> Till now, everything went ok, but sometimes, in the last few days, I
> found some postgres (<zombie>) processes and when every client is
> logging out, another postgres <zombie> process appears. I had to kill
> -SIGTERM the master, wait for 5 or 6 seconds and then restart it again.
> When 1 postgres <zombie> process is appearing, the current working
> clients can work ahead, no problem at all. But newer connections aren't
> accepted.
This sounds like the postmaster process has gotten hung up somehow ---
it's not responding to incoming connection requests, nor is it noticing
SIGCHLD (signal that one of its child processes exited --- the zombies
are there because the postmaster hasn't done a wait() to reap them).
I've never seen this myself, but it sure sounds like a bug.
Next time you see the condition, would you kill the postmaster with a
signal that will produce a coredump (SIGABRT or SIGSEGV should work)
and extract a backtrace from the core file? That will give us more
to go on. Note it will help if you've compiled the backend with -g ...
and don't throw away the corefile, we may need to ask more questions.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 1999-01-25 15:51:02 | Re: [HACKERS] Another source of snprintf/vsnprintf code |
| Previous Message | Oleg Broytmann | 1999-01-25 15:34:26 | Re: [HACKERS] Re: datetime regress test busted by incomplete checkin |