Re: Tables dissapearing
От | Adrian Klaver |
---|---|
Тема | Re: Tables dissapearing |
Дата | |
Msg-id | 200708271839.32792.aklaver@comcast.net обсуждение исходный текст |
Ответ на | Re: Tables dissapearing (Kamil Srot <kamil.srot@nlogy.com>) |
Ответы |
Re: Tables dissapearing
Re: Tables dissapearing |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: