Hey, I found something that finally clears netstat's recv-q with async notifies. I don't quite understand what's going on, so any enlightenment would be greatly appreciated. As near as I can figure, the client doesn't appear to read the notifies until it sends a notify of its own. Then it reads all pending notifies at once and clears the recv-q.
For instance, I can open up two connections on my test server and illustrate the problem. Here's the netstat before everything. [EMAIL PROTECTED] ~ $ netstat | grep mitchell tcp 0 0 ator.cs.wisc.edu:34279 mitchell.cs.wisc:postgresql ESTABLISHED tcp 0 0 ator.cs.wisc.edu:34280 mitchell.cs.wisc:postgresql ESTABLISHED Connection 1: csdb=> listen req; LISTEN Connection 2: csdb=> notify req; NOTIFY (repeat 5 times) Netstat as of now (after 5 notifies): [EMAIL PROTECTED] ~ $ netstat | grep mitchell tcp 70 0 ator.cs.wisc.edu:34279 mitchell.cs.wisc:postgresql ESTABLISHED tcp 0 0 ator.cs.wisc.edu:34280 mitchell.cs.wisc:postgresql ESTABLISHED Connection 1: csdb=> notify req; NOTIFY Asynchronous notification "req" received from server process with PID 7268. Asynchronous notification "req" received from server process with PID 7268. Asynchronous notification "req" received from server process with PID 7268. Asynchronous notification "req" received from server process with PID 7268. Asynchronous notification "req" received from server process with PID 7268. Asynchronous notification "req" received from server process with PID 7267. Netstat as of now: [EMAIL PROTECTED] ~ $ netstat | grep mitchell tcp 0 0 ator.cs.wisc.edu:34279 mitchell.cs.wisc:postgresql ESTABLISHED tcp 0 0 ator.cs.wisc.edu:34280 mitchell.cs.wisc:postgresql ESTABLISHED This does make some sense given our code (the listening connection only listens, it never sends out notifies of its own). However, this doesn't seem like expected behavior. I found nothing in the docs to suggest this being the norm, and it seems odd to require a connection to issue a notify itself before being able to read pending notifies from another connection. Any ideas? Peter ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
