Re: windows doesn't notice backend death

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: windows doesn't notice backend death
Date: 2009-05-03 09:16:36
Message-ID: 49FD60F4.6080408@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>
>>> Tom Lane wrote:
>>>
>>>> Ick. Is it possible that the postmaster did get a report, but thought
>>>> it was normal session termination? If so, how could we distinguish?
>>>>
>>
>>
>>> If that were the case then it would not have the dead process still
>>> listed as a live backend, ISTM, which it does.
>>>
>>
>> The postmaster does not control the content of the pg_stat_activity
>> view.
>>
>>
>>
>
> Well, I'm not I know how to find out the answer to your question. I
> could try attaching a debugger to the postmaster - if I knew where to
> put a breakpoint.

I'd start at pgwin32_deadchild_callback(). That's where the waiting
thread should activate once a child goes away.

That one should post a notice to the win32ChildQueue, which is polled in
win32_waitpid() - that's a second good point for a breakpoint.

This in turn should make things happen up in reaper() - as Alvaro
suggests, a third good place for a breakpoint.

FWIW, this certainly used to work. So we've either broken this recently,
or it's always been broken on Vista (I've never tried it myself on
Vista, only 2000, XP and 2003).

//Magnus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2009-05-03 09:28:45 Re: windows shared memory error
Previous Message Alvaro Herrera 2009-05-03 03:51:30 Re: windows doesn't notice backend death