Обсуждение: 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 19319495 > > Have 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