-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
(Jeff Davis: I've not changed the function, so it's not the plan cache) Tom Lane wrote: > Does the mentioned OID actually correspond to the OID of the table it's > supposed to be opening, or is it wrong? Is anything being done to > the table schema in parallel? Yes, it is the correct OID. No, nothing done to the schema in parallel, although there is a process that disables/re-enables triggers and rules on that table via pg_class tweaking (inside a txn, of course). > If the table is occasionally dropped and recreated... Yeah, that's the first thing I thought of, but it's definitely not being dropped and recreated. Alvaro Herrera wrote: >> It would help if you could get a stack trace at the moment of the >> problem, but I'm not sure how to do that. > > Perhaps insert an abort() call right before the elog(ERROR) > that's reporting this. (I think there are three possibilities, > but they're all in heapam.c so you might as well just hack them all.) Argh, that will have to be a last resort measure, as this is a production system. Have not been able to duplicate yet on a dev box, but will look into adding the abort() for when/if I can duplicate it there. Thanks everyone. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200612201412 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFFiYtwvJuQZxSWSsgRArEbAJ9udj9/Kh2Vi45A8ej3YCC2RKESwgCcCkT8 5ZnN0+yCU0rQ6+PuHtJRtnw= =C1gB -----END PGP SIGNATURE----- ---------------------------(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
