Fri Mar 11 15:48:41 PST 2005
- Previous message: [Slony1-general] disabling triggers
- Next message: [Slony1-general] Moving Towards Slony-I 1.1
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 3/10/2005 3:32 PM, David Parker wrote: > This is not strictly a slony question, but it has to do with some slony > procedure code I would like to emulate... I have a data broadcasting > functionality that is layered on top of a slony installation that I use > to get data replicated out to nodes from a central location without > those nodes having to be part of this slony cluster (all nodes are > actually pairs, Active/Standby, and we are using our trusty slony to > maintain data redundancy between them). > > When a node subscribes I want to do an initial delete/copy of a set of > tables the way slony does, but I need to get around FK constraints. My > understanding of the altertableforreplication procedure is: > > - for each table that needs to be altered and has > triggers/constraints > -update the pg_triggers record for each trigger to point to > the table's primary key object (maintained > in the sl_table table) > - update the record for the current table in pg_class to > decrement the reltriggers column > > And then the restore reverses this process. > > The procedure also disables rules - are both of these steps necessary to > "disable" constraints, or is it sufficient to just point the triggers > away? > > I'm not sure I can implement this the same way, because I don't > necessarily have a primary key to substitute with on all of the target > tables, but I can build in some other kind of table to my schema to help > track these relations. > > But first, am I understanding correctly the way altertableforreplication > works?! This is precisely how it is done. The fact that the pg_trigger rows do not contain the relations OID any more is the key point here. That causes the triggers not to be loaded into the relation descriptor (on heap_open()) and therefore not being fired, or even known by the executor. Rewrite rules are just another mechanism that can cause side effects on INSERT/UPDATE/DELETE. If you want to do a DELETE+COPY, then you better make sure you don't have any ON DELETE rules on those tables. COPY does not invoke rules. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck at Yahoo.com #
- Previous message: [Slony1-general] disabling triggers
- Next message: [Slony1-general] Moving Towards Slony-I 1.1
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list