Re: Cancel/Kill backend functions - Mailing list pgsql-patches

From Tom Lane
Subject Re: Cancel/Kill backend functions
Date
Msg-id 15592.1085725485@sss.pgh.pa.us
Whole thread Raw
In response to Re: Cancel/Kill backend functions  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List pgsql-patches
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> I could write it to save the xid's in PGPROC in a first pass, then
> release the SInvalLock, then look at pg_subtrans.  But I think doing it
> this way has a ("is a?") race condition.

The way that would be technically correct is to *first* look in
pg_subtrans to resolve the xid up to a main xid, then look in PGPROC
to see if that main xact is still active.  (You can return "no"
immediately if the sub-xact is aborted, but that would require yet
another probe into pg_clog, which might not be worth the trouble.)

Of course that's likely to be unpleasantly slow.  Making it faster is an
exercise for the student ;-).

It's worth considering here that the normal case might very soon be that
most tuples are in fact modified by subtransactions.  So I would not
advise optimizing on the assumption that you won't normally have to look
at pg_subtrans.

IIRC there was some discussion of keeping subtrans IDs up to some
limited nesting depth right in PGPROC.  I'm not sure that would help a
whole lot (it helps with a positive answer, but not with a negative).

            regards, tom lane

pgsql-patches by date:

Previous
From: Sean Chittenden
Date:
Subject: Small doc patch for area() function...
Next
From: "Serguei Mokhov"
Date:
Subject: Russian translation updates for 7.5