From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Rushabh Lathia <rushabh(dot)lathia(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Subject: | Re: ERROR: missing chunk number 0 for toast value |
Date: | 2014-01-02 19:21:15 |
Message-ID: | 52C5BC2B.1000604@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/02/2014 02:24 PM, Rushabh Lathia wrote:
> Hi All,
>
> Test case:
>
> drop table if exists t;
> create table t(c text);
> insert into t values ('x'), (repeat(md5('abcdefghijklmnop'), 10000));
> select pg_column_size(c), pg_column_size(c || '') FROM t;
>
> CREATE OR REPLACE FUNCTION copy_toast_out() RETURNS VOID AS $$
> declare
> v text;
> BEGIN
> SELECT c INTO v FROM t WHERE c <> 'x';
> Select 1/0;
> Exception
> When Others Then
> PERFORM pg_sleep(30); -- go run "TRUNCATE t" in a 2nd session
>
>
> raise notice 'length :%', length(v || ''); -- force detoast
>
>
> END;
> $$ language plpgsql;
>
> postgres=# select copy_toast_out();
> ERROR: missing chunk number 0 for toast value 16390 in pg_toast_16384
> CONTEXT: PL/pgSQL function copy_toast_out() line 10 at RAISE
>
> Analysis:
>
> The basic problem here is that if the lock is released on table before
> extracting toasted value, and in meantime someone truncates the table,
> this error can occur. Here error coming with PL block contains an Exception
> block (as incase there is an exception block, it calls
> RollbackAndReleaseCurrentSubTransaction).
This is another variant of the bug discussed here:
http://www.postgresql.org/message-id/0C41674C-FA02-4768-9E1B-548E568875BD@quarantainenet.nl.
> Do you think we should detoast the local variable before
> RollbackAndReleaseCurrentSubTransaction ? Or any other options ?
Hmm, that would fix this particular test case, but not the other case
where you DROP or TRUNCATE the table in the same transaction.
The simplest fix would be to just detoast everything on assignment but
that was rejected on performance grounds in that previous thread. I
don't see any other realistic way to fix this, however, so maybe we
should just bite the bullet and do it anyway. For simple variables like,
in your test case, it's a good bet to detoast the value immediately;
it'll be detoasted as soon as you try to do anything with it anyway. But
it's not a good bet for record or row variables, because you often fetch
the whole row into a variable but only access a field or two. Then
again, if you run into that, at least you can work around it by changing
your plpgsql code to only fetch the fields you need.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-01-02 19:27:18 | Re: preserving forensic information when we freeze |
Previous Message | Andres Freund | 2014-01-02 19:16:43 | Re: proposal: multiple read-write masters in a cluster with wal-streaming synchronization |