Skip site navigation (1) Skip section navigation (2)

Re: pg_listener entries deleted under heavy NOTIFY load only on Windows

From: "Marshall, Steve" <smarshall(at)wsi(dot)com>
To: <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: pg_listener entries deleted under heavy NOTIFY load only on Windows
Date: 2009-01-27 22:46:33
Message-ID: 8536F69C1FCC294B859D07B179F0694411A4CEF8@EXCHANGE.ad.wsicorp.com (view raw or flat)
Thread:
Lists: pgsql-bugs
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?

Thanks,
Steve

-----Original Message-----
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
src/backend/commands/async.c

			if (kill(listenerPID, SIGUSR2) < 0)
			{
+				elog(LOG, "kill(%d) failed: %m",
listenerPID);
				/*
				 * 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 OliveiraDate: 2009-01-28 02:07:20
Subject: Re: BUG #4632: Duplicate
Previous:From: Tom LaneDate: 2009-01-27 21:45:53
Subject: Re: BUG #4633: Bug in PL/PgSQL "SELECT .. INTO" statement parser

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group