Sat Jan 23 04:58:18 PST 2010
- Previous message: [Slony1-general] CREATE SET timeout
- Next message: [Slony1-general] lightweight DDLs changes method (would this break?)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi, I've too much traffic to find an edge between locks. I can hardly afford an application outage. Using Slony 1.2.15, pg 8.2 and 8.3, having only one replication set. My DDLs changes are usually pretty trivial (mostly "ADD COLUMN"): they only touch one table at time, they they don't rename things, they never alter primary keys, they don't add triggers or rewrite rules. All replicated tables have their own, explicit primary keys (no add key). Looking quickly at slony's source code, I thought this may be sufficient to run my ALTERs on replicated tables, avoiding an heavyweight "EXECUTE SCRIPT": BEGIN; LOCK TABLE mytable; -- Wait for pending events touching this table to propagate on subscribers. -- Then run the same "BEGIN ; LOCK TABLE mytable;" on all subscribers. -- On all nodes ALTER mytable ... -- On origin node (only there?) SELECT _mycluster.alterTableRestore(42); SELECT _mycluster.alterTableForReplication(42); -- On all nodes (origin and subscribers) COMMIT; Would this work or did I overlooked something? I wonder if the alterTableRestore and alterTableForReplication are mandatory on subscribers, or only on origin. EXECUTE SCRIPT run them everywhere but this doesn't look necessary when we're not touching triggers/rewrites (?). And I'm not sure whether it would be wise to stop slon daemons meanwhile. My understanding is that when avoiding ddlScript_complete(), aforementioned actions wouldn't generate any event, so slon wouldn't notice anything. Thanks
- Previous message: [Slony1-general] CREATE SET timeout
- Next message: [Slony1-general] lightweight DDLs changes method (would this break?)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list