Laurette Cisneros <laurette@nextbus.com> writes:
> Ok, my production server had this problem (again). So, here's the info.
> you requested. There's a lot of postgres processes still left running:
> postmaster (proc id 1457):
> (gdb) print Shutdown
> $1 = 2
Okay, so the postmaster definitely got the FastShutdown request ...
> postgres 1468 1457 0 Feb06 ? 00:04:57 postgres: nbadmin db1 111.123.123.244 idle
> InterruptPending: $1 = 65537
> proc_exit_inprogress: $2 = 0
> ProcDiePending: $3 = 1
> ImmediateInterruptOK = $4 = 0
> InterruptHoldoffCount = $5 = 0
> CritSectionCount = $6 = 0
... and it correctly sent it on to the backends, because they all have
ProcDiePending true, which proves that the die() signal handler did run.
So why are they sitting waiting for input? They should have exited,
either instantly in die() if it occurred while they were already waiting
for input, or at the CHECK_FOR_INTERRUPTS() just before they next called
ReadCommand(). I can't see any window for failure there.
I'm baffled. The only thing I can see to investigate is that
InterruptPending printed out as 65537 in each backend. It's declared as
bool, and only ever set to true or false, so I'd have expected a result
of 0 or 1 --- in fact, since bool is char, it's impossible for it to
contain a value of 65537. Is gdb confused, or is there something fishy
there?
BTW, do you have any idea whether any backends *did* exit? Is this all
of the ones that were running, or did some obey the shutdown signal?
(You could look for "This connection has been terminated by the
administrator." errors in the postmaster log to see if any did obey.)
regards, tom lane
