Theo Schlossnagle <[EMAIL PROTECTED]> writes:
> In production today (8.1.4), I ran into a backend process that
> wouldn't cancel right away -- minutes went by.
> It was in
> [0] TransactionIdIsCurrentTransactionId
> [1] HeapTupleSatisfiesSnapshot
> ...
> But the interesting thing is that there
On Sep 14, 2006, at 8:19 AM, Gregory Stark wrote:
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
We don't use savepoint's too much. Maybe one or two across out 1k
or so
pl/pgsql procs.
Well if they're in a loop...
We use dbi-link which is plperl. Perhaps that is somehow creating
subtra
Gregory Stark <[EMAIL PROTECTED]> writes:
> Ok, I more or less see what's going on. plperl creates a subtransaction
> whenever you execute an SPI query from inside a perl function. That's so that
> errors in the query can throw perl exceptions and be caught in the perl code.
It might also be wor
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
> We don't use savepoint's too much. Maybe one or two across out 1k or so
> pl/pgsql procs.
Well if they're in a loop...
> We use dbi-link which is plperl. Perhaps that is somehow creating
> subtransactions?
Ok, I more or less see what's going on.
On Sep 14, 2006, at 7:03 AM, Gregory Stark wrote:
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
But the interesting thing is that there were 4.6 million elements
in the
s->childXids list. Which is why it took so damn long. I can't
quite figure
out how I induced this state. It is an OL
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
> But the interesting thing is that there were 4.6 million elements in the
> s->childXids list. Which is why it took so damn long. I can't quite figure
> out how I induced this state. It is an OLAP server with about 10-20
> connection that run "lo
