Terry Lee Tucker <terry@esc1.com> writes:
> All this works great except for certain cases where one of the notify
> messages, the one I'm really interested in, gets spooled, queued, or
> something and is not delivered until I send another notification, after the
> fact, from another client; then, I finally get the message delivered along
> with the one I just sent.
What PG version is this? Some of what you mention sounds a bit like old
bugs, but not enough to be sure. Also, are you using SSL?
AFAIK the only gotcha on the server side in current code is that it
won't send notify messages while you are within a transaction; so if you
are using BEGIN/COMMIT that could be the source of the issue.
Looking at the source for PQconsumeInput, I note that depending on the
kernel behavior it may not read all available data; so you might try
turning that call into a loop
while (PQconsumeInput(conn) > 0)
/* loop */ ;
Ordinarily this is not necessary because if the socket remains
read-ready you should get another callback right away anyway. But
perhaps the X toolkit is doing something weird that suppresses
repeated callbacks.
> I tried calling CheckForNotifies() from the interface code after the
> save operation, but then, after two back to back updates, or sometimes
> just one, the PQsendQuery call hangs up. The only way to "unhang it"
> is to issue a NOTIFY from another client, which allows PQsendQuery to
> continue.
That's just plain bizarre. Can you get a stack trace to find out
exactly where it's hung? And what is the server process doing at
the same time?
regards, tom lane