On Monday 27 August 2007 5:57 pm, Kamil Srot wrote: > Tom Lane wrote: > > Kamil Srot <kamil.srot@xxxxxxxxx> 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@xxxxxxxxxxx ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
