Re: Logging conflicted queries on deadlocks
От | Tom Lane |
---|---|
Тема | Re: Logging conflicted queries on deadlocks |
Дата | |
Msg-id | 20346.1206158931@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Logging conflicted queries on deadlocks (Gregory Stark <stark@enterprisedb.com>) |
Список | pgsql-patches |
Gregory Stark <stark@enterprisedb.com> writes: > Ah, reading the patch I see comments indicating that yes that's possible and > no, we don't really care. So, ok. If the backend disappears entirely could the > string be empty? Right, we'd be pointing at a BackendStatusArray entry that was now unused, or even perhaps recycled by a new session. That memory doesn't move, so we don't need to worry about picking up something that's not a status string at all, but worst case it could be not the string we want. I think the odds are pretty low though. Perhaps it would be safer to copy out st_activity inside the > loop checking st_changecount? Don't think it would really help any --- the other backend could've aborted and changed its status string before we ever get to this code at all. > It is a really nice feature though. Note that there was an unrelated demand > for just this info on one of the other lists just today. Thanks very much > Itagaki-san! That was my feeling --- the usefulness is high enough that a small probability of a wrong display is a small price to pay. regards, tom lane
В списке pgsql-patches по дате отправления: