Re: unable to dump database, toast errors
От | Jan Wieck |
---|---|
Тема | Re: unable to dump database, toast errors |
Дата | |
Msg-id | 3E916257.B23E0DB2@Yahoo.com обсуждение исходный текст |
Ответ на | Re: unable to dump database, toast errors (Lonni Friedman <lfriedman@vasoftware.com>) |
Ответы |
Re: unable to dump database, toast errors
|
Список | pgsql-general |
Lonni Friedman wrote: > yes, its got several other integer & text datatype fields. Lonni, just to let you know, we have all the time in the world and after all it is your problem. So if you slow down the process by giving the informaiton one drop at a time, we can certainly play that game. Just don't blame us that it takes that long then. Is there any of those other columns that could identify a single row uniquely? If so, that could work as a key for this purpose. If you have that, let's call it <keycolumn>. Then do a select <keycolumn> from artifact_file limit 1 offset 694. The key you've got now will be most likely the row containing the corrupted toast value. To check that it is the only one, let's say you got <keyvalue> from the query above. Now do a select sum(length(bin_data)) from artifact_file where <keycolumn> != <keyvalue> If that completes without an error, you found a way to identify the damaged row without using LIMIT. I think Tom already explained what can be done from here. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-general по дате отправления: