On 12/1/2005 4:57 PM, Christopher Browne wrote:

> Idea #2 is then to restructure the material in remote_listen.c so that
> if we see, for a given slon+node, that communications are going well, we
> turn off the LISTEN (which will eliminate pg_listener tuple generation)
> and instead poll...  Every listener that you eliminate eliminates a
> barrel of dead pg_listener tuples...  If each node is working well, then
> this would mean that there are NO listeners, therefore NO pg_listener
> entries, and therefore NO bloat there at all.  That's the tougher change.

How could this have escaped me?

You are right, if there are no listeners, then a notify is just a NOP. 
So if anything that today relies on notifications just unlistens after 
getting one, then polls for let's say 60 seconds, extending the polling 
period if something is found ... and only if it didn't find anything for 
60 seconds it will LISTEN again and wait.

We then have to significantly increase the timeout interval, in which we 
generate SYNC no matter if we detected any change or not. Forcing a SYNC 
and thereby a NOTIFY every 60 seconds, followed by 60 seconds of polling 
... we could as well just poll and forget everything else.

But this is indeed a much better solution that what I had in mind so 
far. Thank you.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #