We have some dozens of places that transiently change CurrentResourceOwner
and then set it back to what it had been. I happened to notice that,
while many of these places have a PG_TRY block to ensure that the restore
happens even if they lose control to an error, not all of them have one.
My initial reaction was that the latter were buggy, since resowner/README
says you should do it with a PG_TRY. On further reflection, though, why
are we paying the rather high price of a PG_TRY block for that? ISTM that
CurrentResourceOwner is much like CurrentMemoryContext, and we certainly
don't worry about protecting transient changes of CurrentMemoryContext
this way. The reason it's safe not to is that the first step in
transaction or subtransaction abort is to reset CurrentMemoryContext to
something sane. But the second step is to reset CurrentResourceOwner
to something sane, so it seems like we have that base covered.
So my inclination is to change the advice in resowner/README and rip out
all the PG_TRY blocks that are used only to force restore of
CurrentResourceOwner. (We might as well leave the code alone in places
where the PG_TRY has to do other things too.)
Thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
