Re: pg_listener entries deleted under heavy NOTIFY load only on Windows
От | Marshall, Steve |
---|---|
Тема | Re: pg_listener entries deleted under heavy NOTIFY load only on Windows |
Дата | |
Msg-id | 8536F69C1FCC294B859D07B179F069441176B988@EXCHANGE.ad.wsicorp.com обсуждение исходный текст |
Ответ на | Re: pg_listener entries deleted under heavy NOTIFY load only on Windows (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_listener entries deleted under heavy NOTIFY load
only on Windows
|
Список | pgsql-bugs |
"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?
В списке pgsql-bugs по дате отправления: