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

From Gregory Stark
Subject Re: Logging conflicted queries on deadlocks
Date
Msg-id 87d4pnr7u6.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Logging conflicted queries on deadlocks  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Logging conflicted queries on deadlocks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
"Gregory Stark" <stark@enterprisedb.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

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