Re: ERROR: missing chunk number 0 for toast value

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, 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-06 14:19:09
Message-ID: 20140106141909.GG28320@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-01-06 09:10:48 -0500, Robert Haas wrote:
> On Thu, Jan 2, 2014 at 4:15 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> >> I think the only principled fixes are to either retain the lock or
> >> forcibly detoast before releasing it.
> >
> > I don't think that's sufficient. Unless I miss something the problem
> > isn't restricted to TRUNCATE and such at all. I think a plain VACUUM
> > should be sufficient? I haven't tested it, but INSERT RETURNING
> > toasted_col a row, storing the result in a record, and then aborting the
> > subtransaction will allow the inserted row to be VACUUMed by a
> > concurrent transaction.
>
> Hmm, that's actually nastier than the case that the case Rushabh
> originally reported.

A bit, yes. Somebody should probably verify that it can actually happen :P

> A somewhat plausible response to "my holdable
> cursor didn't work after I truncated the table it read from" is "well
> don't do that then". But this case could actually happen to someone
> who wasn't trying to do anything screwy.

Personally I think everything that involves using data computed in an
aborted subtransaction but the error code is screwy. I think plpgsql has
been far too lenient in allowing that in an unconstrained fashion.

I actually vote for not allowing doing so at all by erroring out when
accessing a plpgsql variable created in an aborted subxact, unless you
explicitly signal that you want to do do so by calling some function
deleting the information about which subxact a variable was created
in. I have seen several bugs caused by people assuming that EXCEPTION
BLOCK/subtransaction rollback had some kind of effects on variables
created in them. And we just don't have much support for doing anything
in that direction safely.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-01-06 14:28:25 Re: ALTER SYSTEM SET command to change postgresql.conf parameters
Previous Message Craig Ringer 2014-01-06 14:12:06 Re: Convert Datum* to char*