Re: 7.3.4 Table corruption

Поиск
Список
Период
Сортировка
Искать
От
Andrew Farmer
Тема
Re: 7.3.4 Table corruption
Дата
Msg-id
412EB2AF.1080502@andrewfarmer.com
Ответ на
Список
Дерево обсуждения
7.3.4 Table corruption Andrew Farmer <mail@andrewfarmer.com>
Re: 7.3.4 Table corruption Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.3.4 Table corruption Andrew Farmer <mail@andrewfarmer.com>
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  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 по дате отправления
От: Kieran McCusker
Дата:
Сообщение: Loading functions
От: Cris Carampa
Дата:
FAQ