On 2014-01-06 09:10:48 -0500, Robert Haas wrote:
> On Thu, Jan 2, 2014 at 4:15 PM, Andres Freund <andres@2ndquadrant.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