Sun Dec 25 13:57:25 PST 2005
- Previous message: [Slony1-general] Bug in RebuildListenEntries (ID: 1485)
- Next message: [Slony1-general] Bug in RebuildListenEntries (ID: 1485)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jan Wieck wrote: >> Is there a reason for not generating all "sensible" sl_listen entries? >> I didn't find any documentation on the performance overhead a >> sl_listen entry causes. > Exactly the "sensible" part of that all is important. Problems arise > when a node receives an event from any set-origin, which has not yet > been processed by its data provider for that set. For example > > 1 -> 2 > > 3 > > 1 being origin, 2 is subscriber, 3 is a new node not subscribed yet. 3 > has paths for 1 and 2, so naturally it would listen on each of them for > their events. If we now subscribe 3 as a cascaded node with 2 as its > data provider, the ENABLE_SUBSCRIPTION event that will follow from node > 1, on which node 3 will start copy_set, must be received by 3 from 2. > That is the only way that 2 at the moment where 3 starts to copy data > actually has data itself. It could still be busy with it's own copy_set, > meaning that not only the data in the tables is missing, the tables > themself aren't in sl_table either yet. Ahhh... That explains alot... So, the following should find "sensible" sl_listen entries for node X, shouldn't it? 1) If a node Y is origin of a set that X subscribes, use the data-provider of that subscription as the sole event-provider for events from Y. 2) Otherwise, check for all neighbours of X if they can receive events from Y without traversing node X. (Taking (1) into account). If they can, use the neighbour as a provider for events from Y. > And to spice this up a little more, reading the events is done async in > the remote_listen thread. They are queued and the remote_worker thread > will process them from the queue. At the moment where node 3 gets the > SUBSCRIBE_SET event, it will have a lot of stuff already queued, so it > better restart ASAP to throw that away and listen again, this time for > all 1-events on 2. Hm.. but this doesn't influence the sl_listen logic, does it? It's more a matter of calling RebuildListenEntries at the right time, either from some other plpgsql function or from slon. BTW, is there a way to disable the automatic generation of sl_listen entries? greetings, Florian Pflug
- Previous message: [Slony1-general] Bug in RebuildListenEntries (ID: 1485)
- Next message: [Slony1-general] Bug in RebuildListenEntries (ID: 1485)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list