On Mon, Jan 6, 2014 at 9:19 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> 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.
So, you want to let users do things that are unsafe, but only if they
ask nicely? That hardly seems right.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
