Jan Wieck JanWieck
Thu Sep 28 08:25:07 PDT 2006
On 9/28/2006 10:38 AM, Andrew Sullivan wrote:
> On Thu, Sep 28, 2006 at 10:33:10AM -0400, Christopher Browne wrote:
> 
>> 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...
> 
> The key point I was trying to make, though, is that the change isn't
> merely a matter of the primary key changing.  For instance, if you
> add a field or rename one, the trigger has the wrong idea about
> what's in the table.  In earlier versions of the trigger, we actually
> didn't check this on the way by in the trigger (for speed), so you
> could get the wrong data attempting to be inserted on the target.  I
> _think_ Jan fixed that by checking at trigger firing time that your
> table matches what the trigger thinks it should have, so that now
> transactions start failing on the origin under some circumstances. 
> (Am I right about that, or are we still subject to the no-checking
> form of the trigger?)

It checks that the table has the same number of columns and it will 
error out if what it thinks to be a key column all of the sudden 
contains a NULL value, but it doesn't actually check if there still is a 
unique constraint over the columns it thinks are key. Now consider a 
table having columns a,b,c,d with a+b being the primary key. For some 
weird reason you drop b and add b again (maybe to change the data 
type?). The physical layout of the table now is a,(bdead),c,d,b and the 
log trigger will still have the kkvv configuration. Since it skips dead 
columns, it will happily continue and the updates in the replication 
data will just say WHERE a=olda AND c=oldc ... the results of which will 
be a tiny bit funny if c isn't unique within a.


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 #



More information about the Slony1-general mailing list