As I posted before, changing the timeout from 1000 to
NMPWAIT_WAIT_FOREVER fixed the problem, or at least moved it such it
does not occur easily anymore.
To better understand the problem, I added debugging as Tom suggested. I
restored timeout on CalledNamedPipe 1000 ms, and reran my tests.
Indeed, kill is encountering an error:
LOG: kill(2168) failed: No such process
I instrumented pgkill to output the value of GetLastError() if
CalledNamedPipe fails. It returned error code 2, which Windows
identifies as ERROR_FILE_NOT_FOUND. The logic in pgkill translates this
Windows error into an errno value of ESRCH.
The Windows error is a bit surprising, at least to me -- I expected
something indicating the pipe was full. Does anyone have a richer
interpretation of this error?
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Marshall, Steve wrote:
>> Any thoughts on how to confirm or deny Theory A?
> Try changing the 1000 to NMPWAIT_WAIT_FOREVER
As long as you're changing the source code, it'd be a good idea to
verify the supposition that kill() is failing, eg in
if (kill(listenerPID, SIGUSR2) < 0)
+ elog(LOG, "kill(%d) failed: %m",
* Get rid of pg_listener entry if it
refers to a PID that no
* longer exists. Presumably, that
backend crashed without
* deleting its pg_listener entries.
This code used to only
If that's right, sprinkling a few debug printouts into src/port/kill.c
would be the next step.
regards, tom lane
In response to
pgsql-bugs by date
|Next:||From: Euler Taveira de Oliveira||Date: 2009-01-28 02:07:20|
|Subject: Re: BUG #4632: Duplicate|
|Previous:||From: Tom Lane||Date: 2009-01-27 21:45:53|
|Subject: Re: BUG #4633: Bug in PL/PgSQL "SELECT .. INTO" statement parser |