On Thu, Jan 2, 2014 at 4:15 PM, Andres Freund <and...@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 <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
