Re: Assertion failure with a subtransaction and cursor

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Assertion failure with a subtransaction and cursor
Date: 2009-12-03 11:08:31
Message-ID: 4B179C2F.5070303@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Fredrik Palm 2009-12-03 11:16:02 BUG #5229: Queing requests when not using psql
Previous Message Craig Ringer 2009-12-03 08:52:16 Re: [BUGS] BUG #5228: Execution of prepared query is slow when timestamp parameter is used