On 12/19/2006 2:57 AM, hubert depesz lubaczewski wrote:
> On 12/18/06, *Jan Wieck* <JanWieck at yahoo.com 
> <mailto: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.

First, if those were new key columns, then the key columns used by Slony 
(still the old set) wouldn't be unique any more and as soon as there are 
multiple matching rows on the replica, all hell will break lose.

But you didn't clearly understand what I was saying. Even for pure data 
columns, there is a problem. If the table has more columns than the 
attkind vector is long the trigger will just test on random bytes if 
they are 'k' or not ... someday it'll hit a 'k' and treat the column at 
that random moment as a key column. So please stop wiggling, there is no 
loophole that allows you to use this method under some circumstances.

> 
>     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 ;-)

One of the necessary steps would be to correct the attkind attribute for 
the log trigger. So the "correct way" (cough, cough) on the origin would 
be to start a transaction, lock the table, alter the table, drop the log 
trigger and add a log trigger that has the corrected attkind definition.


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 #