Re: Help: unfixable/undead error - missing chunk number 0 for toast value 413511 in pg_toast_25477

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Maris Jansons <maris(at)lailio(dot)net>
Cc: Jorge Torralba <jorge(dot)torralba(at)gmail(dot)com>, pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Help: unfixable/undead error - missing chunk number 0 for toast value 413511 in pg_toast_25477
Date: 2017-01-26 16:03:03
Message-ID: 4224.1485446583@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Maris Jansons <maris(at)lailio(dot)net> writes:
> I have identified the problematic column, in my case it is api_response, my version of script:
> DO $f$
> DECLARE
> baddata TEXT;
> badid INT;
> BEGIN
> FOR badid IN SELECT id FROM api_logs LOOP
> BEGIN
> SELECT api_response
> INTO baddata
> FROM api_logs where id = badid;
> EXCEPTION
> WHEN OTHERS THEN
> RAISE NOTICE 'Data for ID % is corrupt', badid;
> CONTINUE;
> END;
> END LOOP;
> END;
> $f$
> However this script finishes without errors, but if I run simple
>> select api_response from api_logs;
> I get:
> ERROR: missing chunk number 0 for toast value 413511 in pg_toast_25477

> Maybe I have messed something up in the script?

Oh ... what is happening, I think, is that the toast pointers are getting
stored into the "baddata" local variable as-is. The problem would only
get detected if the system has to fetch the toasted value, and this code
doesn't make it do so.

You could do something that requires fetching the value, perhaps

SELECT api_response || '' INTO baddata ...

regards, tom lane

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Maris Jansons 2017-01-27 08:44:58 Re: Help: unfixable/undead error - missing chunk number 0 for toast value 413511 in pg_toast_25477
Previous Message Maris Jansons 2017-01-26 09:44:21 Re: Help: unfixable/undead error - missing chunk number 0 for toast value 413511 in pg_toast_25477