Re: can you have any idea about toast missing chunk issu resolution

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: can you have any idea about toast missing chunk issu resolution
Дата
Msg-id 54B85BA2.1010800@BlueTreble.com
обсуждение исходный текст
Ответ на can you have any idea about toast missing chunk issu resolution  (M Tarkeshwar Rao <m.tarkeshwar.rao@ericsson.com>)
Список pgsql-hackers
On 1/15/15 6:22 AM, M Tarkeshwar Rao wrote:
> We are getting following error message on doing any action on the table like(Select or open from pgadmin).

Error reports should go to pgsql-general. I'm moving the discussion there (and BCC'ing -hackers).

> Please suggest.
>
> ERROR:  missing chunk number 0 for toast value 54787 in pg_toast_2619
>
> ********** Error **********
>
> ERROR: missing chunk number 0 for toast value 54787 in pg_toast_2619
>
> SQL state: XX000

That means that the database tried to detoast a value and it couldn't find it in the toast table. Likely causes:

- Someone manually modified the toast table. Hard to do, but not impossible.
- The toast index is corrupted. toast_fetch_datum() will always use a toast index so the only way to see if this is the
issueis to try REINDEXing. 
- The index is fine and the toast table is corrupted.
- The base table is corrupted. I think a corrupt index on the base table could also cause this, but I'm not sure.
- You've found some bug in either the toast or detoast code.

Note that when I say 'corrupted', that could also mean that the data is there and simply isn't being considered as
visibleper MVCC rules. Also, the actual condition throwing this error is 

    if (nextidx != numchunks)

where

    numchunks = ((ressize - 1) / TOAST_MAX_CHUNK_SIZE) + 1;

and nextidx is incremented with every chunk that's read.

The easiest thing to try right now is a REINDEX and see if that fixes things. It would be best if you stopped the
serverand made a filesystem copy of the data directory before doing that (or at least pg_clog, pg_xlog and the relevant
toastheap and index files). 
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Bug in pg_dump
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]