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
From: [email protected]
On Behalf Of Hannu
Sent: Tuesday, August 30, 2005 7:28 AM
To: Andreas Pflug
Cc: [email protected]
Subject: [Slony1-general] Re: [HACKERS] dangling lock information?
On E, 2005-08-29 at 13:09 +0200, Andreas Pflug wrote:
Hannu Krosing wrote:
On P, 2005-08-28 at 22:23 +0200, Andreas Pflug wrote:
I'm currently testing pgAdmin support for slony, on pgsql CVS HEAD,
and encounter strange problems from time to time.
After dropping and recreating the slony schema, all changes
committed and all backends in <IDLE> state, I'm getting "relation
with OID xxx does not exist" when I'm trying to add a path.
This seems to be triggered inside slony functions when a
LOCK _test.pg_config IN EXCLUSIVE MODE is performed.
The problem is gone as soon as I close the connection I've been
using for prior schema changes, and use a fresh connection.
Does this description ring a bell for somebody?
seems like the usual "pl/pgsql caches query plans and relation
referenced inside the cached plan is gone" thing
Kind of, but the complete schema including procedures was dropped, so
apparently after recreation the old plans were reused?!?
In that case this should probably be asked at slony list.
Added to CC.