On 2014-01-02 15:00:58 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-01-02 21:21:15 +0200, Heikki Linnakangas wrote:
> >> I don't see any other realistic way to fix this, however, so maybe we
> >> should just bite the bullet and do it anyway.
>
> > We could remember the subtransaction a variable was created in and error
> > out if it the creating subtransaction aborted and it's not a
> > pass-by-value datum or similar.
>
> That would still result in throwing an error, though, so it isn't likely
> to make the OP happy.
Yea, it would give a better error message which might help diagnose the
issue, but not more. We could disallow accessing such variables
generally unless they explicitly had been detoasted, that would make
people notice the problem more easily.
I shortly wondered if we couldn't "just" iterate over plpgsql variables
and detoast them on subabort if created in the aborted xact, but that
doesn't really work because we're in an aborted transaction where it
might not be safe to access relations... Theoretically the subabort
could be split into two phases allowing it by only releasing the lock
after safely switching to the upper transaction but that sounds like a
hammer too big for the problem.
> 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...
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services