Re: ERROR: unexpected chunk number 0 (expected 1) for toast value 76753264 in pg_toast_10920100

From: adsj(at)novozymes(dot)com (Adam =?utf-8?Q?Sj=C3=B8gren?=)
To: pgsql-general(at)postgresql(dot)org
Subject: Re: ERROR: unexpected chunk number 0 (expected 1) for toast value 76753264 in pg_toast_10920100
Date: 2018-04-05 16:03:23
Message-ID: 877eplej3o.fsf@tullinup.koldfront.dk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom writes:

>> And when I run the suggested query, I get:
>
>> efamroot(at)kat efam=# select chunk_id, chunk_seq, ctid, xmin, xmax, length(chunk_data) from pg_toast.pg_toast_10919630 where chunk_id = 1698936148 order by 1,2;
>> chunk_id | chunk_seq | ctid | xmin | xmax | length
>> ------------+-----------+--------------+------------+------+--------
>> 1698936148 | 0 | (52888694,2) | 1511390221 | 0 | 1996
>> 1698936148 | 1 | (52888694,4) | 1511390221 | 0 | 1148
>> (2 rows)

> Hmph. So if you EXPLAIN that query, does it show it's doing it as an
> indexscan? I'd expect so, but it's always good to make sure.

It does:

efamroot(at)kat efam=# SELECT * FROM efam.sendreference WHERE id = '189909908';
ERROR: unexpected chunk number 0 (expected 1) for toast value 1698936148 in pg_toast_10919630
efamroot(at)kat efam=# select chunk_id, chunk_seq, ctid, xmin, xmax, length(chunk_data) from pg_toast.pg_toast_10919630 where chunk_id = 1698936148 order by 1,2;
chunk_id | chunk_seq | ctid | xmin | xmax | length
------------+-----------+--------------+------------+------+--------
1698936148 | 0 | (52888694,2) | 1511390221 | 0 | 1996
1698936148 | 1 | (52888694,4) | 1511390221 | 0 | 1148
(2 rows)

efamroot(at)kat efam=# explain select chunk_id, chunk_seq, ctid, xmin, xmax, length(chunk_data) from pg_toast.pg_toast_10919630 where chunk_id = 1698936148 order by 1,2;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------
Index Scan using pg_toast_10919630_index on pg_toast_10919630 (cost=0.57..2627179.25 rows=2135674 width=54)
Index Cond: (chunk_id = 1698936148::oid)
(2 rows)

> Assuming it does say that, then the other test I had in mind would
> involve "set enable_indexscan = 0", then repeat the EXPLAIN to make
> sure that you now get a seqscan plan (you might need to turn off
> enable_bitmapscan too), then do the query again and see whether the
> results are the same.

Ok (if I don't disable bitmapscan, I get Bitmap Heap Scans in the EXPLAIN, so):

efamroot(at)kat efam=# set enable_indexscan = 0;
SET
efamroot(at)kat efam=# set enable_bitmapscan = 0;
SET
efamroot(at)kat efam=# explain select chunk_id, chunk_seq, ctid, xmin, xmax, length(chunk_data) from pg_toast.pg_toast_10919630 where chunk_id = 1698936148 order by 1,2;
QUERY PLAN
-------------------------------------------------------------------------------------
Sort (cost=96465280.57..96470619.75 rows=2135674 width=54)
Sort Key: chunk_seq
-> Seq Scan on pg_toast_10919630 (cost=0.00..96240754.39 rows=2135674 width=54)
Filter: (chunk_id = 1698936148::oid)
(4 rows)

efamroot(at)kat efam=# select chunk_id, chunk_seq, ctid, xmin, xmax, length(chunk_data) from pg_toast.pg_toast_10919630 where chunk_id = 1698936148 order by 1,2;
[... still waiting for the result, I will return with what it said
when the server does ...]

Best regards,

Adam

--
"No more than that, but very powerful all the Adam Sjøgren
same; simple things are good." adsj(at)novozymes(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jorge Daniel 2018-04-05 17:02:18 Docker + postgreSQL : OOM killing in a large Group by operation
Previous Message Peter Eisentraut 2018-04-05 15:52:38 Re: [PATCH] Logical decoding of TRUNCATE