The oid in question does not correspond to a relfilenode, and
oid2name -o 94144936 doesn't return anything when run against the
database in question.
Could this be related to temp tables? We use a lot of them in data
imports, and this was a point of discussion on IRC.
Having a limited understanding of postgres internals, I apologize if
any of the following sound like nonsensically wild hairs:
Does VACUUM (under the auspices of pg_autovacuum) attempt to vacuum
temp tables, which are otherwise not visible outside of a given session?
Does bgwriter operate on temp tables, and could there exist an edge
condition in which bgwriter might have scheduled a write to disk for
a file corresponding to a temp table that was removed by sudden
termination of the session in which the temp table existed such that
the file was removed?
One of the puzzling things to me, for instance, is that this error
persisted, so we're wondering if maybe bgwriter refused to do any
more writing because the thing it was scheduled to write ceased to
exist without telling it.
In the aftermath, a pg_dump (combined with pg_restore for
verification) completed successfully. Do I still have cause for concern?
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
Strategic Open Source: Open Your i™
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005
On Jul 14, 2005, at 7:57 AM, Tom Lane wrote:
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
Anyway, if I do a lookup by oid for 94144936 in pg_class, I don't see
it. And, clearly, it's not in $PGDATA/base/32019395.
You should be looking at relfilenode. See
http://www.postgresql.org/docs/8.0/static/storage.html
and/or use oid2name to figure out what table is being complained of.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
