Miguel wrote: > Christopher Browne wrote: > >> Miguel wrote: >> >> >> >>> does slony need exclusive lock for this initial transfer? >>> >>> >>> >> >> It will ultimately need exclusive locks on the subscriber in order to >> complete the copy, as it will be modifying the table schemas a bit. >> >> >> > I dont mind exclusive lock on the subscribers, but the master node is > my production machine, i cant stop the applications during the > initial transfer. > Reading the docs , in section 10 Locking Issues, you can read > > Unfortunately, there are several sorts of Slony-I events that do > require exclusive locks on PostgreSQL tables, with the result that > modifying Slony-I configuration can bring back some of those "locking > irritations." In particular: > > [...] > * During the COPY_SET event on a new subscriber > In a sense, this is the least provocative scenario, since, before the > replication set has been populated, it is pretty reasonable to say > that the node is "unusable" and that Slony-I could reasonably demand > exclusive access to the node. > [...] > > I understand that during the initial transfer, the cluster is unusable > by the applications, is this asumption correct? > No, happily you are incorrect about that.
The *subscriber* is either partly or entirely locked up (there are some variations based on time and what version of Slony-I you are running). But the *provider* doesn't involve those locks. On the origin, there is a brief table lock required when SET ADD TABLE is run; that action modifies the table to add the logtrigger trigger and stored procedure. But that is just a very brief lock, once, independently, for each table. That shouldn't destroy the usability of the "master node." >>> also, if i dont start the slon process, the master node operate in >>> normal "mode" , i mean, slony-i agnostic? >>> >>> >>> >> >> I'm not quite sure what you mean by that. >> >> If you don't start a slon for the node that is the origin for a set, >> then: >> >> - tuples will build up in sl_log_1 as tables that were added to >> replication sets are modified, and will never be cleaned out. >> - no SYNC events will get issued, thereby preventing event activity from >> propagating. >> >> Maybe you could explain what you think a "normal mode" is, or what >> "Slony-I agnostic" means; we might be able to correct some >> misunderstandings, there... >> >> >> > with your explanations, all is clear now, > with agnostic and normal i mean like there isnt any slony program > installed, but you are right, the slony overhead is always there, only > the replication process is stopped, the sl_log_1 will grow a lot, > thanks If you can suggest where that section of the documentation could be made clearer, that would be useful, and I'd be more than happy to improve that. _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
