""=?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.
-- 
(format nil "~S@~S" "cbbrowne" "ca.afilias.info")
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)