This this a new TODO? ---------------------------------------------------------------------------
Jan Wieck wrote: > Gaetano Mendola wrote: > > > Bruce Momjian wrote: > > > >> I can confirm this bug in CVS. > > Dropping the pkey from table b in fact drops the unique index from it. > The SPI plan cached to check if a row deleted from table a is still > referenced from table b "can" (and in your case does) use an index scan > on table b and is thereby corrupted by dropping the pkey. > > Switching to a generally non-cached model for all foreign key checks > would be the only workaround at the moment, and I don't see us doing > that as it would cause performance to suffer big times for everyone > who's system doesn't have a permanent "what's the latest schema" contest > going on. > > Since all caching procedural languages and all caching custom C > functions suffer the same, the correct fix would be to let > SPI_saveplan() maintain a hash table of all referenced system cache > objects who's entries point to the referencing saved plans and then mark > those plans for recompile at system cache invalidation. > > I will probably not do it today ... tomorrow doesn't look good either. > > > Jan > > -- > #======================================================================# > # It's easier to get forgiveness for being wrong than for being right. # > # Let's break this rule - forgive me. # > #================================================== [EMAIL PROTECTED] # > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
