Tue Mar 7 12:04:53 PST 2006
- Previous message: [Slony1-general] What is left for 1.2???
- Next message: [Slony1-general] Exuberant Subscriber Table Locking at Subscribe Time
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jim C. Nasby wrote: >On Tue, Mar 07, 2006 at 03:36:57PM +0800, Christopher Kings-Lynne wrote: > > >>>What used to happen is that the tables would gradually get locked, >>>piecemeal, as Slony-I got to each one. You could run into deadlock >>>problems right near the end, which is a real waste. By locking them >>>up front, any failures will take place before any data is copied, so >>>this minimizes time wastage. >>> >>> >>Which is exactly why pg_dump does the saem thing. >> >> > > > No, this is NOT like pg_dump. pg_dump takes out locks on the data *provider* that would cause DDL requests to get held back. The relevant behaviour under discussion is about what happens on the SUBSCRIBER; the node that is receiving the data. >Wait, are we talking about exclusive locks here? Or do we just aquire >shared locks to prevent anyone from running DDL against the objects? > > This is exclusive locks, but let me make it clear, the locking under discussion is taking place on the SUBSCRIBER, not on the ORIGIN. On the subscriber, the rough set of things that are done used to be: - Check that the 22 tables being replicated are there, and have PK/candidate PK Then, for each table... - Delete all existing entries from it; if we have subtransactions, then try to truncate it (TRUNCATE will take out a pretty exclusive lock) - Copy the data from the source endloop Alter all 22 tables to add the "denyaccess()" trigger In 1.2, it changes a bit... - Check that the 22 tables being replicated are there, and have PK/candidate PK. Lock the table as we go... Then, for each table... - Delete all existing entries from it; if we have subtransactions, then try to truncate it (TRUNCATE will take out a pretty exclusive lock) - Copy the data from the source endloop Alter all 22 tables to add the "denyaccess()" trigger. It sounds to me as though there might be value in having a slon option that controls the two bits of "particularly lock-happy" logic so that, for people who really know what they are doing, the locking regimen can be less, erm, "harsh." Proposal for alternative: RFC There is a case to be made that people might want to have access to the old data until such time as it gets replaced by new data. (And if they drop a "deadlock bomb" on Slony-I, that's the risk they are taking on...) Thus, if the option, oh, call it "subscriber_lock", which defaults to 1, is set to 0, then some if clauses won't be invoked: if (subscriber_lock) { lock_table(n); } if (subscriber_lock) { try_to_truncate_table(n); } else { just_delete_from(n); } Does that seem like a good idea? Does anyone see anything particularly horrible about that idea?
- Previous message: [Slony1-general] What is left for 1.2???
- Next message: [Slony1-general] Exuberant Subscriber Table Locking at Subscribe Time
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list