Re: unable to dump database, toast errors
От | Lonni J Friedman |
---|---|
Тема | Re: unable to dump database, toast errors |
Дата | |
Msg-id | Pine.LNX.4.44.0304031335570.3031-100000@beefcake.hdqt.vasoftware.com обсуждение исходный текст |
Ответ на | Re: unable to dump database, toast errors (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: unable to dump database, toast errors
|
Список | pgsql-general |
On Thu, 3 Apr 2003, Tom Lane wrote: > Lonni J Friedman <lfriedman@vasoftware.com> writes: > > ok, i've got 786 rows to play with, joy. once i find a broken row/field, > > how do I map that back to pg_toast_302323? > > Well, it'll tell you which chunk_id it's having a problem with; you > could then look into the toast table to see what the available data is. > (Although the odds are good that the data will have been compressed, so > you won't be able to tell much :-() hrmmm...i'm not sure that the results i'm getting are matching up with your description of what should occur. This query: select * from artifact_file LIMIT 1 OFFSET 31; consistantly results in psql seg faulting. If I reduce or increase the OFFSET then the query succeeds. So, i was assuming that row 34 (since you said its N+2) has bad data. BUt from what you're saying it sounds like i should be seeing a toast error as an indication of the bad data, and that isn't happening (at least not in the first 60 rows that i've selected so far). Am i missing something obviously boneheaded here? thanks!
В списке pgsql-general по дате отправления: