-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tom Lane wrote: > Oh! Duh, that's your issue right there, I'll bet. The problem is that > relcache-open tries to read the pg_class row under SnapshotNow rules, > and if there is another xact concurrently modifying the row, it is > entirely possible for none of the row versions to be committed good at > the instant they are visited. (The new row version either isn't seen at > all or isn't committed good yet when it's visited, and later when the > old row version is visited, it has become committed dead.) This results > in ScanPgRelation failing (returning NULL) which leads to exactly the > "could not open relation with OID xxx" symptom --- and in fact I see no > other code path that yields that failure. Doesn't this violate ACID, or am I misunderstanding something? (FWIW, I'm using a serializable isolation level for the process that changes pg_class) > As of 8.2 we have this problem fixed for system-initiated changes to the > pg_class row, but you're still going to be at risk if you are doing > manual "UPDATE pg_class" operations. Can you get away from needing to > do that? ALTER TABLE DISABLE TRIGGER might help, but we haven't got > anything like ALTER TABLE DISABLE RULE. Yeah, triggers alone won't do it. Sounds like a TODO item - Bruce? > In any case the important point is that you have to take AccessExclusive > lock on a relation whose pg_class row you would like to change, and you > need to be on 8.2 because prior releases weren't careful about obtaining > lock *before* reading the row. Obtaining an AccessExclusive lock is a last resort, as the tables in question are very busy. That's another reason why DISABLE TRIGGER might not work out either. - -- Greg Sabino Mullane [EMAIL PROTECTED] End Point Corporation PGP Key: 0x14964AC8 200701021325 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFFmqU9vJuQZxSWSsgRAgZ4AJ4wBUI6APz658zaE8bFQ5xmILFiugCgxfsW GI2zgdF6l/tmxWpnO4J9dms= =NtIn -----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
