Joel Burton <jburton@scw.org> writes:
> Yikes. It gets weirder.
> Fixed the pg_inherits problem, went back to my Zoping, trying to optimize
> some views, and during another run, get an error that trelclasspq, one of
> my tables, couldn't open.
> Trying this out in psql, I get the same error message--the file doesn't
> exist. And, getting the oid for the file, looked in the directory--and
> this file is gone too!
This does not seem good. Just to clarify: in both cases, the pg_class
row for the table is still there, but the underlying Unix file is gone?
Barring major malfeasance from your kernel, it seems like Postgres must
be issuing a delete on the wrong file when you are doing something else.
This is particularly bizarre if you are just doing create/delete view,
because in 7.1 a view hasn't got any associated file, and so no unlink()
kernel call should be issued at all.
I would recommend that you try to narrow down the events leading up to
this --- in particular, keeping a postmaster log of queries issued (-d2)
seems like a good idea.
> I doubt the error is Zope *per se*,
Zope cannot be the culprit --- there is no API for deleting a table file
without deleting its pg_class entry ;-). But it seems possible that
some peculiar pattern of queries that they issue could be triggering a
previously-unknown Postgres bug.
I will be out of town all day tomorrow, but please see what data you can
gather. If you can create a reproducible failure case it'd be great...
regards, tom lane
