2006/12/19, hubert depesz lubaczewski <depesz at gmail.com>:
> On 12/18/06, Jan Wieck <JanWieck at yahoo.com> wrote:
> > The problem is that from the moment there are more columns than the
> > trigger knows about, update and delete statements let the trigger access
> > the attkind (that funny 'kvvvvvv' string) info past its end. Meaning,
> > the check if to include that column into the WHERE clause of the
> > replication update/delete is done against random bytes on the stack. If
> > one of them happens to be a 'k', the trigger will attempt to add it and
> > its value to the where clause and if that value happens to be a NULL
> > your transaction will go kaput.
>
> do i understand correctly, that this insecure way of adding columns would
> actually work as long as i dont add "key" column?
> please do understand my question - i know it is not appropriate way of doing
> things. i know it is not supported. but i just would like to know real
> limits.
>
> > Andrew is right, I actually didn't add that check. But this whole
> > discussion makes me think about adding it again ...
> >
>
> but why? this single thing is actually a great point - you can *technically*
> add a column without any interruptions, just do it in correct order, with
> neccessary steps, and it *should* work. nobody gives any guarantees, but hey
> - that's how the software is built - nobody gives any guarantees ;-)

If you really want to know, I got some conclusions about it after
reading src/backend/slony1_funcs.c

When you already have PK on the table, and you are adding nullable
fields this way, worst case you can get is:
ERROR:  Slony-I: old key column TTT.FFF IS NULL on {UPDATE,DELETE}

So you will not be able to update or delete rows. Transaction will rollback.

This will happen only sometimes, if both TTT.FFF IS NULL,
and the famous "read data out of array bounds" gets 'k' in
_Slony_I_logTrigger function

see code for details :)


-- 
Filip Rembia?kowski