Re: [HACKERS] pg_inherits: not found, but visible [IT GETS WORSE]
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! Now, I just made a good dump of the database, so I can always go back to that. But this seems to be a *serious* problem in the system. I have Zope 2.3.1b2 (most recent version of Zope) running on a Linux-Mandrake 7.2 box (server #1) It has a database adapter called ZPoPy, which is the Zope version of PoPy, a Python database adapter for PostgreSQL. PoPy is getting data from my PostgreSQL database, which is 7.1beta4, and served on a different Mandrake 7.2 box. Has anyone seen anything like this? I doubt the error is Zope *per se*, since Zope can only talk to the database adapter, and I doubt the database adapter has the intentional feature of delete-the-file-for-this-table in its protocol. It *could* be a problem w/ZPoPy or PoPy; I'll send a message to their list as well. Thanks! -- Joel Burton [EMAIL PROTECTED] Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] pg_inherits: not found, but visible [IT GETS WORSE]
On Tue, Mar 20, 2001 at 08:03:16PM -0500, Joel Burton wrote: Yikes. It gets weirder. I have Zope 2.3.1b2 (most recent version of Zope) running on a Linux-Mandrake 7.2 box (server #1) What kind of filesystem is the pgsql data tree living on? If you do a fsck, does anything turn up in lost+found? Ross ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] pg_inherits: not found, but visible [IT GETS WORSE]
Joel Burton [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
