Re: Tables dissapearing
От | Erik Jones |
---|---|
Тема | Re: Tables dissapearing |
Дата | |
Msg-id | CA999C1F-F46F-4BE5-B749-8D51BFE0A3D7@myemma.com обсуждение исходный текст |
Ответ на | Re: Tables dissapearing (Kamil Srot <kamil.srot@nlogy.com>) |
Ответы |
Re: Tables dissapearing
|
Список | pgsql-general |
On Aug 27, 2007, at 7: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! Also, I'd write a simple "ping" script to check for the table that runs every 5 seconds or so. Have it, at the very least, write out the timestamp of when the table disappears into a file. Better yet would be for it to send you an alert so you can check it out right away. With that *when* you'll know *where* in your logs to look to see what happened at that time. Erik Jones Software Developer | Emma® erik@myemma.com 800.595.4401 or 615.292.5888 615.292.0777 (fax) Emma helps organizations everywhere communicate & market in style. Visit us online at http://www.myemma.com
В списке pgsql-general по дате отправления: