On Monday 27 August 2007 5:57 pm, Kamil Srot wrote:
> Tom Lane wrote:
> > Kamil Srot <kamil.srot@nlogy.com> 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
aklaver@comcast.net
