Skip site navigation (1) Skip section navigation (2)

Re: Logging conflicted queries on deadlocks

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

In response to

Responses

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2008-03-22 01:56:39
Subject: Re: Proposal: new large object API
Previous:From: Gregory StarkDate: 2008-03-21 23:00:18
Subject: Re: Logging conflicted queries on deadlocks

pgsql-patches by date

Next:From: Tatsuo IshiiDate: 2008-03-22 01:56:39
Subject: Re: Proposal: new large object API
Previous:From: Gregory StarkDate: 2008-03-21 23:00:18
Subject: Re: Logging conflicted queries on deadlocks

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group