Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> The logical next step would be to get rid of the interXact concept
>> altogether and always associate temporary files with the current
>> resource owner; the caller should switch to a sufficiently long-lived
>> one before calling.
>
> That would mean having a session-lifespan resource owner, which doesn't
> seem amazingly useful to me: we have no other resource types for which
> that would be even a little bit sane.
The only user of "interXact == true" is when the result set of a
holdable cursor is materialized. I'm envisioning a new resource owner
alongside PortalData.holdContext which is the memory context used to
hold the tuplestore.
> I'm inclined to leave the temp
> file API as nearly as possible as-is. Having it attach only xact-local
> files to the CurrentResourceOwner sounds fine to me.
Ok, fine with me.
> One thought here is that my inclination would be to keep
> CleanupTemporaryFiles in place and have it just look for temp files that
> didn't get closed, as a debugging aid. This is comparable to the
> behavior of other modules that are mostly driven by resource managers.
> We didn't take out the end-of-xact checks when we added resource manager
> support elsewhere, and I'm not inclined to do that here. I agree we
> don't need an EOSubXact-time crosscheck, though.
Ok, committed that way. I made the cross-check a WARNING. That seems
like the right level of seriousness, although I see that many of the
other similar checks are Asserts.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com