Re: ERROR: missing chunk number 0 for toast value

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: ERROR: missing chunk number 0 for toast value
Дата
Msg-id 52C5BC2B.1000604@vmware.com
обсуждение исходный текст
Ответ на ERROR: missing chunk number 0 for toast value  (Rushabh Lathia <rushabh.lathia@gmail.com>)
Ответы Re: ERROR: missing chunk number 0 for toast value  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: ERROR: missing chunk number 0 for toast value  (Andres Freund <andres@2ndquadrant.com>)
Re: ERROR: missing chunk number 0 for toast value  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: proposal: multiple read-write masters in a cluster with wal-streaming synchronization
Следующее
От: Andres Freund
Дата:
Сообщение: Re: preserving forensic information when we freeze