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 по дате отправления: