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. #
#================================================== [EMAIL PROTECTED] #
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
