Thanks for the reply Tom. See comments below:
On Thursday 24 February 2005 12:06 pm, Tom Lane saith:
> 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?
I never remember this until after I've sent the message. Here it is:
rnd=# select version ();
version
--------------------------------------------------------------------------------------------------------------
PostgreSQL 7.4.6 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 3.2.3
20030502 (Red Hat Linux 3.2.3-49)
>
> 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.
The message is being sent inside a transaction by an after update trigger that
updates values in another table.
>
> 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 */ ;
I will give this a try.
> 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?
I will be happy to do this if you or someone else will tell me how to do it.
>
> regards, tom lane
Thank you for your help ;o)