Tom Lane wrote:
> Heikki Linnakangas writes:
>> 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.
>
> Looks good. I'm a bit tempted to rename the interXact argument to
Heikki Linnakangas writes:
> 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.
Looks good. I'm a bit tempted to rename the interXact argument to
something like noOwner --
Tom Lane wrote:
> Heikki Linnakangas 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 mea
Heikki Linnakangas 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-lifespa
Heikki Linnakangas wrote:
> Tom Lane wrote:
>> So as far as I can tell at the moment, temp files really are the only
>> problem, and making them be managed by resource owners instead of a
>> subxact-based release policy should fix that.
>
> Ok, good.
>
>> I can go work on that, unless you wante
Heikki Linnakangas writes:
> Tom Lane wrote:
>> I can go work on that, unless you wanted to?
> I started hacking on that when I posted, so I can finish it.
Sounds good. I added a bit to the ROLLBACK TO reference page to remind
us what we think the behavior is supposed to be for cursor rollback.
Tom Lane wrote:
> So as far as I can tell at the moment, temp files really are the only
> problem, and making them be managed by resource owners instead of a
> subxact-based release policy should fix that.
Ok, good.
> I can go work on that, unless you wanted to?
I started hacking on that when
I wrote:
> Heikki Linnakangas writes:
>> Hmm, I think we should track temporary files using resource owners.
> That would probably be a workable solution if temp files are the only
> problem. What I'm afraid of is that this type of problem exists
> *everywhere* that we track the need for cleanup
Tom Lane wrote:
> Heikki Linnakangas writes:
> > Tom Lane wrote:
> >> Not sure what to do. The only fix that seems bulletproof at the moment
> >> is to declare that any cursor that's been touched at all in a
> >> subtransaction is marked "broken" if the subtransaction rolls back.
> >> That might
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Not sure what to do. The only fix that seems bulletproof at the moment
>> is to declare that any cursor that's been touched at all in a
>> subtransaction is marked "broken" if the subtransaction rolls back.
>> That might be too great a loss of funct
Tom Lane wrote:
> Heikki Linnakangas writes:
>> On all versions starting from 8.0 where subtransactions were introduced,
>> this causes an assertion failure:
>
> Ugh :-(
>
> This ties into the more general issue that it's not clear what effect a
> subtransaction rollback should have on a cursor.
Heikki Linnakangas writes:
> On all versions starting from 8.0 where subtransactions were introduced,
> this causes an assertion failure:
Ugh :-(
This ties into the more general issue that it's not clear what effect a
subtransaction rollback should have on a cursor. You could argue that
ideally
On all versions starting from 8.0 where subtransactions were introduced,
this causes an assertion failure:
postgres=# BEGIN;
BEGIN
postgres=# DECLARE foocur CURSOR FOR SELECT a FROM
generate_series(1,50) a;
DECLARE CURSOR
postgres=# SAVEPOINT sp;
SAVEPOINT
postgres=# FETCH foocur;
a
───
1
(1
13 matches
Mail list logo
