[EMAIL PROTECTED] ("David Parker") writes:
> The slony log trigger saves execution plans, so any given connection
> that has been used with a slony schema installed will have cached OIDs
> referring to the sl_log_1 table. When you drop the schema, those OIDs
> obviously go away. When you re-create the schema, and try to use the old
> connection, it still has the old plan cached in it, so the OIDs in the
> plan are out of sync with what actually exists in the database.
>
> This is the behavior I've observed in our environment, anyway. The
> problem always shows up when slony is RE-installed under an outstanding
> connection.I have observed much the same behaviour... It would be really useful to have some guidance as to how to resolve this. What is needed is to invalidate the cached execution plans. Unfortunately, it's not at all obvious how to accomplish that :-(. Alas, any time I touch the SPI code in other than relatively trivial ways, it falls over and croaks :-(. -- let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;; http://cbbrowne.com/info/linuxdistributions.html One good turn gets most of the blankets. ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
