>>>>> "Robert" == Robert Haas <robertmh...@gmail.com> writes:

 Robert> I don't see a reason why MakeTransitionCaptureState needs to
 Robert> force the tuplestores into TopTransactionContext or make them
 Robert> owned by TopTransactionResourceOwner.

Nor do I, and I'm pretty sure it's leaking memory wholesale within a
transaction if you have aborted subxacts.

e.g. a few iterations of this, on a table with an appropriate trigger:

savepoint s1;
insert into foo
  select i, case when i < 100000 then repeat('a',100)
            else repeat('a',1/(i-100000)) end
    from generate_series(1,100000) i;
rollback to s1;

This is a bit contrived of course but it shows that there's missing
cleanup somewhere, either in the form of poor choice of context or
missing code in the subxact cleanup.

 Robert> I mean, it was like that before, but afterTriggers is a global
 Robert> variable and, potentially, there could still be a pointer
 Robert> accessible through it to a tuplestore linked from it even after
 Robert> the corresponding subtransaction aborted, possibly causing some
 Robert> cleanup code to trip and fall over.  But that can't be used to
 Robert> justify this case, because the TransitionCaptureState is only
 Robert> reached through the PlanState tree; if that goes away, how is
 Robert> anybody going to accidentally follow a pointer to the
 Robert> now-absent tuplestore?

For per-row triggers with transition tables, a pointer to the transition
capture state ends up in the shared-data record in the event queue?


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to