Stefan Kaltenbrunner <ste...@kaltenbrunner.cc> writes:
> On 06/22/2012 08:34 PM, Tom Lane wrote:
>> Still, panther is NetBSD so there may be some general BSD flavor to
>> whatever's going on here.
> yeah the threading reference was mostly because all backtraces contain
> references to threading libs and because the threading tests are the
> last ones done by the ECPG changes...
It is weird that this seems to be happening only in the context of the
ecpg and isolation tests, because it's not clear why client-side
activity would have anything to do with it. Your gdb investigations
confirm that all the actual client-serving backends are gone, and the
postmaster knows it. But the background service processes haven't shut
down. AFAICS the postmaster could not have reached PM_WAIT_BACKENDS
state without signaling them, so why aren't they shutting down, and why
does it matter which set of tests we'd been running?
My first thought about it was that maybe a signal got missed, but it's
hard to credit that bgwriter, walwriter, and autovac would all have
missed signals concurrently. (checkpointer and stats collector don't
get signaled yet, so it's not surprising those are still around.)
I wonder whether signal_child() could have failed? It logs about
such failures, but only at debug3 which seems overly taciturn.
I wonder if we should crank that up to LOG level.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
