From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | pgsql-interfaces(at)postgresql(dot)org, Junaili Lie <junaili(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: <IDLE> in transaction |
Date: | 2005-08-20 03:29:32 |
Message-ID: | 20050820032932.GA18659@surnet.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-interfaces |
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)
From | Date | Subject | |
---|---|---|---|
Next Message | CSN | 2005-08-20 04:59:21 | Suggestion for Date/Time Functions Section |
Previous Message | Tom Lane | 2005-08-20 02:38:32 | Re: Upgrade OS from Redhat AS3 (2.4 kernel) to AS4 (2.6) |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2005-08-22 00:20:00 | Re: DBD::Pg performance bites compared to DBD::mysql? |
Previous Message | elein | 2005-08-20 01:01:40 | Re: <IDLE> in transaction |