Thread: pg_dump: ERROR: could not open relation with OID ...
During a routine backup procedure (that does not run nightly) for an 8.2.3 postgres cluster, pg_dump failed:
pg_dump: Error message from server: ERROR: could not open relation with OID ...
In doing some log forensics, I discovered that this error has been showing up in the logs intermittently unconnected to pg_dump for the past 6 days. It's not occurring at an alarming rate, but the fact that it's occurring at all is mildly alarming, and the fact that it's preventing backups is even more alarming.
In reviewing the logs, one OID in particular shows up in the vast majority of the errors, and it doesn't correspond to any entries I can find in pg_class. A handful of other OIDs show up, and a sampling of them reveals, too, no entries in pg_class.
The other curious item is that a number of the errors occur in a pattern where they precede other error statements and don't seem to be directly tied to connections, except during the failed pg_dumps.
The typical pattern in the logs is:
[timestamp] [pid] [remote host/port]:ERROR: [error message]
[timestamp] [pid] [remote host/port]:STATEMENT: [statement]
With this error, though, the format doesn't include the remote host/port, which makes me wonder if it's occurring as a result of autovacuum or other local/internal activity.
Now my thoughts return nervously to a previous thread:
I didn't think much of it at the time, but now I wonder if it was indicative of trouble on the way?
--
Thomas F. O'Connell
optimizing modern web applications
: for search engines, for usability, and for performance :
Thomas F. O'Connell wrote: > During a routine backup procedure (that does not run nightly) for an > 8.2.3 postgres cluster, pg_dump failed: > > pg_dump: Error message from server: ERROR: could not open relation > with OID ... > > In doing some log forensics, I discovered that this error has been > showing up in the logs intermittently unconnected to pg_dump for the > past 6 days. It's not occurring at an alarming rate, but the fact > that it's occurring at all is mildly alarming, and the fact that it's > preventing backups is even more alarming. > > In reviewing the logs, one OID in particular shows up in the vast > majority of the errors, and it doesn't correspond to any entries I > can find in pg_class. A handful of other OIDs show up, and a sampling > of them reveals, too, no entries in pg_class. OIDs that show up more than a couple of times are likely to be stored in a catalog somewhere. The first place I'd look is pg_depend and pg_shdepend. Other places that mention OIDs related to relations are pg_constraint, pg_rewrite, pg_description, pg_shdescription, pg_trigger, pg_type, pg_autovacuum; but all of them would most likely be used only if a pg_class tuple references those, so it's unlikely that it's those at fault. -- Alvaro Herrera http://www.PlanetPostgreSQL.org/ "No necesitamos banderas No reconocemos fronteras" (Jorge González)