X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 925EF529EF;
	Sat, 20 Aug 2005 00:28:56 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 41909-04; Sat, 20 Aug 2005 03:28:54 +0000 (GMT)
Received: from mx1.surnet.cl (mx1.surnet.cl [216.155.73.180])
	by svr1.postgresql.org (Postfix) with ESMTP id 1E11C52A20;
	Sat, 20 Aug 2005 00:28:45 -0300 (ADT)
Received: from unknown (HELO cluster.surnet.cl) (216.155.73.164)
	by mx1.surnet.cl with ESMTP; 19 Aug 2005 23:28:49 -0400
X-IronPort-AV: i="3.96,127,1122868800"; d="scan'208"; a="308176:sNHT28532304"
Received: from alvh.no-ip.org (200.85.218.40) by cluster.surnet.cl (7.0.043)
	(authenticated as alvherre@surnet.cl)
	id 42B3EF60008C6A3E; Fri, 19 Aug 2005 23:28:41 -0400
Received: by alvh.no-ip.org (Postfix, from userid 1000)
	id 46CACC2DC2A; Fri, 19 Aug 2005 23:29:32 -0400 (CLT)
Date: Fri, 19 Aug 2005 23:29:32 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: pgsql-interfaces@postgresql.org, Junaili Lie <junaili@gmail.com>,
	pgsql-general@postgresql.org
Subject: Re: <IDLE> in transaction
Message-ID: <20050820032932.GA18659@surnet.cl>
Mail-Followup-To: pgsql-interfaces@postgresql.org,
	Junaili Lie <junaili@gmail.com>, pgsql-general@postgresql.org
References: <8d04ce990508181616c93fbbc@mail.gmail.com>
	<20050819000218.GS5365@varlena.com>
	<20050819185519.GY5365@varlena.com>
	<20050819230602.GM15622@surnet.cl>
	<20050820010140.GC5365@varlena.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050820010140.GC5365@varlena.com>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=1.917 required=5 tests=[AWL=-0.859,
	DNS_FROM_RFC_ABUSE=0.374, DNS_FROM_RFC_POST=1.376,
	RCVD_IN_NJABL_PROXY=1.026]
X-Spam-Level: *
X-Archive-Number: 200508/1065
X-Sequence-Number: 82473

On Fri, Aug 19, 2005 at 06:01:40PM -0700, elein wrote:

> To replicate the situation in psql:
> 	BEGIN;
> 	select something;
> 
> In another window I see that I have not only shared access locks
> but an exclusive access lock.  I do not understand why the exclusive
> lock is there.  Am I seeing ghosts?

No, it's the lock on the transaction's own TransactionId.  It's harmless
until the transaction updates a tuple that some other transaction later
wants to update too.  You should be able to see it too if you don't
issue the SELECT.  The point of the modification I was indicating is to
delay the acquisition of such a lock until the transaction actually does
something, like that SELECT.  (So if the client does exactly what you
did, it wouldn't be solved by my proposed change.)

-- 
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"In a specialized industrial society, it would be a disaster
to have kids running around loose." (Paul Graham)