Re: Proposed toast info extraction function for disaster recovery
От | Tom Lane |
---|---|
Тема | Re: Proposed toast info extraction function for disaster recovery |
Дата | |
Msg-id | 24810.1118431568@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposed toast info extraction function for disaster recovery (Alvaro Herrera <alvherre@surnet.cl>) |
Ответы |
Re: Proposed toast info extraction function for disaster
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@surnet.cl> writes: > Now that I think about it, maybe my problem is not related to TOAST at > all, but to a corrupted varlena field. Right. > So if the corruption does not > involve toasting, I'm in the same position as before, i.e. I haven't > found out what is the corrupted tuple. Hmm. Maybe we need something more like a "lint check" for tables, ie run through and look for visibly corrupt data, such as obviously impossible lengths for varlena fields. (I thought about adding more checks to the standard code paths, such as heap_deformtuple, but aside from the speed penalty involved, most of those places don't actually have enough context to issue a useful error message. A "lint check" could reasonably expect to tell you by ctid which tuple has a problem.) Come to think of it, didn't someone already write something close to this a few years ago? regards, tom lane
В списке pgsql-hackers по дате отправления: