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

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: Logging conflicted queries on deadlocks
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Logging conflicted queries on deadlocks