Re: 7.3.4 Table corruption
От | Andrew Farmer |
---|---|
Тема | Re: 7.3.4 Table corruption |
Дата | |
Msg-id | 412EB2AF.1080502@andrewfarmer.com обсуждение исходный текст |
Ответ на | Re: 7.3.4 Table corruption (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-admin |
Thanks for the advice. I'll relax the constraints on the table, and reload that table from the dump, might take a while to fix any problems, but it should be safer. Regards, Andrew Tom Lane wrote: >Andrew Farmer <mail@andrewfarmer.com> writes: > > >>My question is, if I load the good dump into a clean database, and then >>find the underlying file that represents the broken table and copy it >>over the top of the broken table, am I likely to face any big problems? >> >> > >This strikes me as a real good way to shoot yourself in the foot ;-). >Better take a backup and be prepared to restore from it. And I'd >suggest experimenting in a scratch installation before you try it for >real. > >Having said that, I think it would work, if your "clean database" is >another DB in the same cluster (you could *not* copy from data prepared >under a different postmaster). And you'll need to copy all the indexes >on that table, and its toast table and toast table index if it has one. >And shut down the postmaster while you do the copying. > > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 4: Don't 'kill -9' the postmaster > > >
В списке pgsql-admin по дате отправления: