"Marshall, Steve" <smarshall@wsi.com> writes:
> Under a heavy load of NOTIFY events, entries in the pg_listener table=20
> for some events are deleted, effectively acting as though UNLISTEN=20
> were called.
> I have only been able to make this occur on a PostgreSQL server=20
> running on Windows.
"tom lane writes":
AFAICS the most likely explanation for this is that Send_Notify() gets
an error from kill() and concludes that the listening process has died
without removing its pg_listener entry; whereupon it removes it itself.
Looking at pgkill(), that theory implies that CallNamedPipe() failed
when under sufficient stress. I'm not sure what the "timeout" parameter
we use with CallNamedPipe actually limits, but maybe it's too small?
(Microsoft's doc suggests that the timeout only matters if the pipe
doesn't already exist, so I'm not sure I believe this theory; though
certainly the doc is vague enough that that reading could be wrong.)
Theory B is that you've got some broken antivirus code on there that is
arbitrarily interfering with the pipe access. The lack of any similar
previous reports suggests that there's some local issue contributing ,,,
To explore Theory B, I'll turn off all non-essential services on the
Windows server and rerun the test. I'll report back with what I find.
Any thoughts on how to confirm or deny Theory A?