Heikki Linnakangas wrote:
> Peter Koczan wrote:
>
>> There is a problem where connections listening for asynchronous notifies
>> occasionally block for writing on ther server side and never finish,
>> resulting in connections that always have the status "notify interrupt".
>> Apparently, this causes no ill effects for the application that's listening
>> (i.e. it still updates somehow), but no data is written to the connection
>> when it should be. It also becomes a problem for restarting the server since
>> postgres cannot kill the connections when they're in that state. I either
>> have to explicitly kill the connections, kill the client apps, or reboot the
>> server. If I try to restart postgres, it kills all but the "notify
>> interrupt" connections, but it doesn't shut down so I can't restart it short
>> of rebooting.
>>
>
> Does the client read the async notifies? The write in the server will
> block if the client doesn't keep up with reading the data.
>
>
Well, the client updates it's GUI properly no matter whether the
listening session is blocked or not (it's an ongoing tail of requests).
Overtly from the client side, it's completely transparent. Is there any
way I can tell definitively from the client side whether or not it's
actually reading the async notifies?
>> ...
>>
>> (This stack trace is of the last 3 updates, and is farily representative of
>> what I've seen).
>> [root(at)vero ~]# strace -p 30728
>>
>
> That's actually not a stack trace, but a system call trace.
>
>
D'oh. sorry, still a little new at using these tools for debugging.