On Saturday 16 September 2006 20:34, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> 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
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> 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 act
Tom Lane <[EMAIL PROTECTED]> writes:
> The real question is why does the subtransaction actually assign itself
> an XID --- a simple RETURN NEXT operation ought not do that, AFAICS.
> What is it you're doing in there that changes the database?
I suspect the answer to that is the same as the answ
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
> The select function is dbi-link's remote_select.
> remote_select will perform the query and then for each row
> return_next which calls the SPI.xs stuff to do plperl_return_next
> which is wrapped in a PG_TRY block. I see the value of the try
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
> I've tracked the problem I mentioned earlier with my 4.5 million node linked
> list of s->childXids down. We use plperl to connect to Oracle over DBI. The
> select function is dbi-link's remote_select. remote_select will perform the
> query and
I've tracked the problem I mentioned earlier with my 4.5 million node
linked list of s->childXids down. We use plperl to connect to Oracle
over DBI. The select function is dbi-link's remote_select.
remote_select will perform the query and then for each row
return_next which calls the SPI
