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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers