From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-patches(at)postgresql(dot)org, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> |
Subject: | Re: Logging conflicted queries on deadlocks |
Date: | 2008-03-22 04:08:51 |
Message-ID: | 20346.1206158931@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Gregory Stark <stark(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-03-22 04:22:49 | Re: Logging conflicted queries on deadlocks |
Previous Message | Tatsuo Ishii | 2008-03-22 01:56:39 | Re: Proposal: new large object API |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-03-22 04:22:49 | Re: Logging conflicted queries on deadlocks |
Previous Message | Tatsuo Ishii | 2008-03-22 01:56:39 | Re: Proposal: new large object API |