On Mon, 2006-12-11 at 12:02 -0500, Christopher Browne wrote:
> ""=?UTF-8?Q?Filip_Rembia=C5=82kowski?="" <plk.zuber at gmail.com> writes:
> 
> > 2006/12/11, Brad Nicholson <bnichols at ca.afilias.info>:
> >> > Add column can always be done without slony help.
> >>
> >> This is false.
> >
> > I think this is true, at least if you take some extra measures to
> > avoid remote worker errors.
> > First of all, you should always enable any restrictions (checks, not
> > null constraints, foreign keys) on master nodes first.
> >
> > Let's assume that you have simple master-slave setup, and you want to
> > ALTER TABLE prod ADD price numeric not null default 0.
> > To be completely safe you can take following steps (make sure that
> > replication lag goes to zero after each step):
> >
> > 1. slave# alter table prod add price numeric
> > 2. master# alter table prod add price numeric
> > 3. master# alter table prod alter price set default 0
> > 4. slave# alter table prod alter price set default 0
> > 5. master# update prod set price=0 where price is null
> > 6. master# alter table prod alter price set not null
> > 7. slave# alter table prod alter price set not null
> >
> > that's all :) remote writers are happy.
> 
> But the origin node is mussed up.
> 
> slonyregress2@[local]:5882=#  alter table table1 add price numeric;
> ALTER TABLE
> slonyregress2@[local]:5882=# \c slonyregress1 
> You are now connected to database "slonyregress1".
> slonyregress1@[local]:5882=#  alter table table1 add price numeric;
> ALTER TABLE
> slonyregress1@[local]:5882=#  alter table table1 alter price set default 0;
> ALTER TABLE
> slonyregress1@[local]:5882=# \c slonyregress2 
> You are now connected to database "slonyregress2".
> slonyregress2@[local]:5882=#  alter table table1 alter price set default 0;
> ALTER TABLE
> slonyregress1@[local]:5882=# \d table1
>                          Table "public.table1"
>  Column |  Type   |                      Modifiers                      
> --------+---------+-----------------------------------------------------
>  id     | integer | not null default nextval('table1_id_seq'::regclass)
>  data   | text    | 
>  price  | numeric | default 0
> Indexes:
>     "table1_pkey" PRIMARY KEY, btree (id)
> Triggers:
>     _slony_regress1_logtrigger_1 AFTER INSERT OR DELETE OR UPDATE ON table1 FOR EACH ROW EXECUTE PROCEDURE _slony_regress1.logtrigger('_slony_regress1', '1', 'kv')
> 
> The trigger is wrong; the argument value 'kv' does not reflect the
> structure of the table.  It should have, as the 3rd argument, the
> value 'kvv'.
> 
> This can be survivable, for a while, maybe, if you're lucky.

I'd strongly recommend that you fix the triggers.  The easiest way is to
run an EXECUTE script - this will drop the triggers and recreated them
properly.  You can also do it manually, table by table if you want.  I
can dig up directions if you need.

However, you are sitting on a time bomb right now. 

-- 
Brad Nicholson  416-673-4106
Database Administrator, Afilias Canada Corp.