Re: Cancel/Kill backend functions
| От | Tom Lane |
|---|---|
| Тема | Re: Cancel/Kill backend functions |
| Дата | |
| Msg-id | 15592.1085725485@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Cancel/Kill backend functions (Alvaro Herrera <alvherre@dcc.uchile.cl>) |
| Список | 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 по дате отправления: