--00032555b95aebd1ec047d836076
Content-Type: text/plain; charset=ISO-8859-1
Hi,
today i run into an issue with postgres 8.3.4 and slony 1.2.15 on solaris
10.
I found hundres of errors in my postgres log file:
ERROR: cache lookup failed for type 177473925
These errors came up directly after dropping a slony cluster completely.
The relevant slony commmands were:
drop set ( id = 1, origin = 1);
drop path ( server = 1, client = 2);
drop path ( server = 2, client = 1);
These commands drop the trigger in the replicated tables.
In the Release Notes of Posgres 8.3 I find
"Automatically re-plan cached queries when table definitions change or
statistics are updated "
and in the slony docs I find something similar:
http://www.pgadmin.org/docs/1.6/slony/faq.html#missingoids
Did I do something wrong?
Is that feature limited to special table alterations or specific platforms?
What can I do to prevent this error - except reestablishing the db
connections of course.
In postgres 8.3 I already could successfully create an index parallel to
another index which was corrupted and drop the corrupted trigger without
reestablishing the db connections.
So basically I'm on the right way.
best regards,
Uwe
--00032555b95aebd1ec047d836076
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi,<br><br>today i run into an issue with postgres 8.3.4 and slony 1.2.15 o=
n solaris 10.<br><br>I found hundres of errors in my postgres log file:<br>=
ERROR:=A0 cache lookup failed for type 177473925<br><br>These errors came u=
p directly after dropping a slony cluster completely.<br>
The relevant slony commmands were:<br>drop set ( id =3D 1, origin =3D 1);<b=
r>drop path ( server =3D 1, client =3D 2);<br>drop path ( server =3D 2, cli=
ent =3D 1);<br><br>These commands drop the trigger in the replicated tables=
..<br><br>
In the Release Notes of Posgres 8.3 I find <br>"Automatically re-plan =
cached queries when table definitions change or statistics are updated &quo=
t;<br>and in the slony docs I find something similar:<br><a href=3D"http://=
www.pgadmin.org/docs/1.6/slony/faq.html#missingoids">http:// www.pgadmin.org=
/docs/1.6/slony/faq.html#missingoids</a><br>
<br>Did I do something wrong?<br>
Is that feature limited to special table alterations or specific platforms?=
<br>
What can I do to prevent this error - except reestablishing the db connecti=
ons of course.<br><br>In postgres 8.3 I already could successfully create a=
n index parallel to another index which was corrupted and drop the corrupte=
d trigger without reestablishing the db connections.<br>
So basically I'm on the right way.<br><br>best regards,<br>Uwe<br><br>
--00032555b95aebd1ec047d836076--
