Re: Backpatch FK changes to 7.3 and 7.2? - Mailing list pgsql-hackers

From Michael Paesold
Subject Re: Backpatch FK changes to 7.3 and 7.2?
Date
Msg-id 01b801c30124$8c915110$3201a8c0@beeblebrox
Whole thread Raw
In response to Re: Backpatch FK changes to 7.3 and 7.2?  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
List pgsql-hackers
Jan Wieck wrote:
> > In any case, why don't we get a patch against 7.3, and make an
> > announcement and let people who are interested use it and test it.  With
> > in-field testing it'd probably be safe enough. :)
>
> Here it is.
>

[patch... skipping]

I applied the patch to a 7.3.2 installation, and did a make clean, make,
make check. There is one regression error. Is this an expected behaviour? Or
did I do something wrong? See regression diffs:

*** ./expected/foreign_key.out  Sun Sep 22 02:37:09 2002
--- ./results/foreign_key.out   Sat Apr 12 20:44:54 2003
***************
*** 882,888 **** ERROR:  $1 referential integrity violation - key in pktable still
referenced from pktable -- fails (1,1) is being referenced (twice) update pktable set base1=3 where base1=1;
! ERROR:  $1 referential integrity violation - key referenced from pktable
not found in pktable -- this sequence of two deletes will work, since after the first there
will be no (2,*) references delete from pktable where base2=2; delete from pktable where base1=2;
--- 882,888 ---- ERROR:  $1 referential integrity violation - key in pktable still
referenced from pktable -- fails (1,1) is being referenced (twice) update pktable set base1=3 where base1=1;
! ERROR:  $1 referential integrity violation - key in pktable still
referenced from pktable -- this sequence of two deletes will work, since after the first there
will be no (2,*) references delete from pktable where base2=2; delete from pktable where base1=2;

Best Regards,
Michael Paesold



pgsql-hackers by date:

Previous
From: Lamar Owen
Date:
Subject: Re: [GENERAL] Upgrade to Red Hat Linux 9 broke PostgreSQL
Next
From: Neil Conway
Date:
Subject: Re: Anyone working on better transaction locking?