On Thu, Jan 2, 2014 at 4:15 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-01-02 16:05:09 -0500, Robert Haas wrote:
>> On Thu, Jan 2, 2014 at 3:19 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> >> I was wondering if we could somehow arrange to not
>> >> release the subtransaction's AccessShareLock on the table, as long as it
>> >> was protecting toasted references someplace.
>> >
>> > Sounds fairly ugly...
>>
>> 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 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company