Andrew Sullivan <ajs at crankycanuck.ca> writes:
> On Wed, Sep 27, 2006 at 01:25:57PM -0700, Richard Yen wrote:
>> Just out of curiosity, where does primary key info, for replicated  
>> tables, get stored by slony?
>
> In its control tables.  It's the key by which the table is referenced
> during a replication event.  That's why it acts funny.

There's a bit more to it...

Things start with running SET ADD TABLE, where either you specify a PK
candidate, or that the PK should be used.  At that time, two things
happen:

1.  sl_table has information stored in it as to the PK choice

2.  A logging trigger is put on the table; you'll see a trigger thus:

Triggers:
    _schema_logtrigger_11 AFTER INSERT OR DELETE OR UPDATE ON my_table FOR EACH ROW EXECUTE PROCEDURE _schema.logtrigger('_schema', '11', 'vvvk')

What controls the key choice at the time data is inserted to the
replicated table is the 'vvvk' part; the logtrigger() function uses
that to determine which columns are "values" and which are part of the
"key."

>> I've found that I can manually use ALTER TABLE commands to add,  
>> remove, or update rows on replicated tables, and slony continues to  
>> run without any complaints.
>
> That's what you think.  It _looks_ that way, but later it is as
> likely as not to blow up.  If you don't use EXECUTE SCRIPT for DDL,
> it _will_ break, and in really unpredictable ways (well,
> unpredictable to those who haven't done it before.  What happens is
> that your triggers have the wrong idea about what your tables look
> like, and you corrupt your replica).  Don't do that. 

Right.

You can modify the primary key as part of EXECUTE SCRIPT; at the end
of EXECUTE SCRIPT, the logtrigger trigger gets regenerated, so that if
the primary key changes, that will be reflected properly.  But not if
you do the alterations outside a script run via EXECUTE SCRIPT...
-- 
(format nil "~S@~S" "cbbrowne" "ca.afilias.info")
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)