Re: The enormous s->childXids problem

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