missing chunk number 0 for toast value
This is for PostgreSQL 7.4.6 on hppa2.0w-hp-hpux11.00, compiled
by GCC 3.2.2. I'm seeing the following 2 errors:
ERROR: missing chunk number 0 for toast value 19319495
ERROR: unexpected chunk number 4 (expected 0) for toast value
19319495
It is always the same toast value. The table has 1.8M rows.
I've identified the column and the row:
$ psql -c "\d audit"
Table "public.audit"
Column | Type | Modifiers
--------+-----------------------------+-----------
value | text |
cdate | timestamp without time zone |
key | text |
Indexes:
"idx_audit_cdate" btree (cdate)
"idx_audit_key" btree ("key")
$ psql -c "select key from audit where key = '791015.o9'"
key
-----------
791015.o9
(1 row)
$ psql -c "select cdate from audit where key = '791015.o9'"
cdate
---------------------
2005-04-06 00:00:00
(1 row)
$ psql -c "select value from audit where key = '791015.o9'"
ERROR: missing chunk number 0 for toast value 19319495
It causes all dumps and any access (via SELECT, UPDATE, and
COPY/pg_dump) to audit.value to fail. I've tried to look at the
underlying toast table per some old posts, but no joy.
As usual, this is on a system with a downtime-sensitive customer.
Any ideas?
Ed
"Ed L." <pgsql@bluepolka.net> writes:
This is for PostgreSQL 7.4.6 on hppa2.0w-hp-hpux11.00, compiled
by GCC 3.2.2. I'm seeing the following 2 errors:
ERROR: missing chunk number 0 for toast value 19319495
ERROR: unexpected chunk number 4 (expected 0) for toast value
19319495
Have you tried REINDEXing the toast table in question?
regards, tom lane
On Wednesday April 27 2005 3:55 pm, Tom Lane wrote:
ERROR: missing chunk number 0 for toast value 19319495
ERROR: unexpected chunk number 4 (expected 0) for toast
value 19319495Have you tried REINDEXing the toast table in question?
Not yet. Any way to repair it without blocking concurrent
access?
Ed
"Ed L." <pgsql@bluepolka.net> writes:
On Wednesday April 27 2005 3:55 pm, Tom Lane wrote:
Have you tried REINDEXing the toast table in question?
Not yet. Any way to repair it without blocking concurrent
access?
Unlikely. But the lock will only affect operations that need to touch
toasted field values.
regards, tom lane
On Wednesday April 27 2005 4:40 pm, Tom Lane wrote:
"Ed L." <pgsql@bluepolka.net> writes:
On Wednesday April 27 2005 3:55 pm, Tom Lane wrote:
Have you tried REINDEXing the toast table in question?
Not yet. Any way to repair it without blocking concurrent
access?Unlikely. But the lock will only affect operations that need
to touch toasted field values.
Does this shed any light? pg_toast_6221538 is the relevant toast
table...
$ psql -c "set enable_indexscan=off; select chunk_seq,
length(chunk_data) from pg_toast.pg_toast_6221538 where chunk_id
= 19319495 order by chunk_seq;"
chunk_seq | length
-----------+--------
(0 rows)
$ psql -c "select chunk_seq, length(chunk_data) from
pg_toast.pg_toast_6221538 where chunk_id = 19319495 order by
chunk_seq;"
chunk_seq | length
-----------+--------
(0 rows)
Ed
"Ed L." <pgsql@bluepolka.net> writes:
Does this shed any light? pg_toast_6221538 is the relevant toast
table...
$ psql -c "set enable_indexscan=off; select chunk_seq,
length(chunk_data) from pg_toast.pg_toast_6221538 where chunk_id
= 19319495 order by chunk_seq;"
chunk_seq | length
-----------+--------
(0 rows)
Doesn't look very promising :-(
regards, tom lane
On Wednesday April 27 2005 6:11 pm, Tom Lane wrote:
"Ed L." <pgsql@bluepolka.net> writes:
Does this shed any light? pg_toast_6221538 is the relevant
toast table...$ psql -c "set enable_indexscan=off; select chunk_seq,
length(chunk_data) from pg_toast.pg_toast_6221538 where
chunk_id = 19319495 order by chunk_seq;"
chunk_seq | length
-----------+--------
(0 rows)Doesn't look very promising :-(
Sorry...what does that mean? Not promising that reindexing the
toast table would help because there is no data there?
Ed