| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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-21 23:11:13 |
| Message-ID: | 87d4pnr7u6.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
"Gregory Stark" <stark(at)enterprisedb(dot)com> writes:
> There's no way the other transaction's timeout could fire while we're doing
> this is there? Are we still holding the lw locks at this point which would
> prevent that?
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? Perhaps it would be safer to copy out st_activity inside the
loop checking st_changecount?
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!
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2008-03-22 01:56:39 | Re: Proposal: new large object API |
| Previous Message | Gregory Stark | 2008-03-21 23:00:18 | Re: Logging conflicted queries on deadlocks |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2008-03-22 01:56:39 | Re: Proposal: new large object API |
| Previous Message | Gregory Stark | 2008-03-21 23:00:18 | Re: Logging conflicted queries on deadlocks |