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

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: M Tarkeshwar Rao <m(dot)tarkeshwar(dot)rao(at)ericsson(dot)com>
Subject: Re: can you have any idea about toast missing chunk issu resolution
Date: 2015-01-16 00:30:26
Message-ID: 54B85BA2.1010800@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general 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 issue is 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 visible per 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 server and made a filesystem copy of the data directory before doing that (or at least pg_clog, pg_xlog and the relevant toast heap and index files).
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jim Nasby 2015-01-16 00:50:03 Re: Simple Atomic Relationship Insert
Previous Message John R Pierce 2015-01-16 00:19:52 Re: Out of Memory

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-01-16 00:37:16 Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
Previous Message Jim Nasby 2015-01-16 00:06:51 Re: Bug in pg_dump