| David Parker 2005-08-30, 7:30 am |
| 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.
- DAP=20
-----Original Message-----
From: slony1-general-bounces- AuKwsB3Fm+ugFIWk8tvy
RWD2FQJk+8+b@public.gmane.org
[mailto:slony1-general-bounces- AuKwsB3Fm+ugFIWk8tvy
RWD2FQJk+8+b@public.gmane.org] On Behalf Of Hannu
Krosing
Sent: Tuesday, August 30, 2005 7:28 AM
To: Andreas Pflug
Cc: slony1-general- AuKwsB3Fm+ugFIWk8tvy
RWD2FQJk+8+b@public.gmane.org; PostgreSQL-development
Subject: [Slony1-general] Re: [HACKERS] dangling lock information?
On E, 2005-08-29 at 13:09 +0200, Andreas Pflug wrote:
> Hannu Krosing wrote:
>=20
> Kind of, but the complete schema including procedures was dropped, so=20
> apparently after recreation the old plans were reused?!?
In that case this should probably be asked at slony list.
Added to CC.
--
Hannu Krosing <hannu-7C/ iILuz2RdeoWH0uzbU5w@
public.gmane.org>
____________________
____________________
_______
Slony1-general mailing list
Slony1-general- AuKwsB3Fm+ugFIWk8tvy
RWD2FQJk+8+b@public.gmane.org
http://gborg.postgresql.org/mailman.../slony1-general
|