Re: can you have any idea about toast missing chunk issu resolution - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: can you have any idea about toast missing chunk issu resolution
Date
Msg-id 54B85BA2.1010800@BlueTreble.com
Whole thread Raw
In response to can you have any idea about toast missing chunk issu resolution  (M Tarkeshwar Rao <m.tarkeshwar.rao@ericsson.com>)
List 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 by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Bug in pg_dump
Next
From: Michael Paquier
Date:
Subject: Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]