On Saturday 16 September 2006 20:34, Tom Lane wrote:
> Gregory Stark <gsstark@mit.edu> writes:
> > Tom Lane <tgl@sss.pgh.pa.us> writes:
> >> The real question is why does the subtransaction actually assign itself
> >> an XID --- a simple RETURN NEXT operation ought not do that, AFAICS.
> >
> > I suspect the answer to that is the same as the answer to what's actually
> > creating the subtransaction. plperl_return_next doesn't. I think
> > something must be doing an actual SPI query, not just a return next.
>
> The other question on the table is why it didn't respond to QueryCancel
> in a reasonable amount of time. I'd really like to see a complete test
> case for this problem ...
>
I think the plperl was a red herring. Once dbi-link grabs a recordset, the
rows are looped over, processed, and then inserted (based on some
conditionals) into another table. Those inserts are wrapped in a
begin....exception block, which, since it is in a loop, I suspect is creating
the large number of childXids in cases where there are a large number of
inserts. I haven't tested that theory, but it seems logical, and should be
easy enough to reproduce with a simple LOOP ... END LOOP in plpgsql.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
