On Monday 27 August 2007 5:57 pm, Kamil Srot wrote:
> Tom Lane wrote:
> > Kamil Srot <[EMAIL PROTECTED]> writes:
> >> Erik Jones wrote:
> >>> Have you verified that the table's files are still on disk after
> >>> it's "disappeared"?
> >>
> >> Do not have any idea how to do it... I wasn't able to access it using
> >> any DML/DDL commands... can try it on a binary backup of the damaged DB
> >> if you'll guide me...
> >
> > Make a note now of the table's "relfilenode" value (it'll be different
> > in each database), and confirm that you see it in the filesystem.  After
> > the next disappearance, see if anything's still there.  For background
> > read
> > http://www.postgresql.org/docs/8.2/static/storage.html
>
> OK, I have the filenames noted and I do confirm, they all does exist now
> under the base in the pgsql tree...
>
> > Note that certain operations like TRUNCATE and CLUSTER change the
> > relfilenode, so if you're using any of those then it might get harder to
> > track where the file is.
>
> There is not any manipulation with the structure of the DB, so it'll
> stay the same...
>
> Thank you!

I have a question. First a little history. Right now, the people who know 
better than I are fairly certain Postgres is not changing things on its own 
and the developer is certain the CMS software is not doing schema changes. As 
I understand it logging has been cranked up to test both those assumptions. 
My question is, how are legitimate schema changes done?  Just wondering if 
there is a third party involved.
-- 
Adrian Klaver
[EMAIL PROTECTED]

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to