Re: Logging conflicted queries on deadlocks - Mailing list pgsql-patches

From Tom Lane
Subject Re: Logging conflicted queries on deadlocks
Date
Msg-id 20346.1206158931@sss.pgh.pa.us
Whole thread Raw
In response to Re: Logging conflicted queries on deadlocks  (Gregory Stark <stark@enterprisedb.com>)
List 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 by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Logging conflicted queries on deadlocks
Next
From: Tom Lane
Date:
Subject: Re: Logging conflicted queries on deadlocks