Re: ExclusiveLock and Python

From: "Michael A(dot) Schulte" <michael(dot)schulte(at)sun(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gaetano Mendola <mendola(at)bigfoot(dot)com>, pgsql-admin(at)postgresql(dot)org
Subject: Re: ExclusiveLock and Python
Date: 2003-02-28 08:57:51
Message-ID: 3E5F248F.8020606@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Tom Lane wrote:
> "Gaetano Mendola" <mendola(at)bigfoot(dot)com> writes:
>
>>select * from pg_locks where mode = 'ExclusiveLock';
>> relation | database | transaction | pid | mode | granted
>>----------+----------+-------------+-------+---------------+---------
>> | | 2560899 | 20404 | ExclusiveLock | t
>
>
>>ExclusiveLock on what ?
>
>
> Your own transaction, that's what.
>
> If one transaction needs to wait for a specific other transaction, it
> does so by attempting to grab ShareLock on the transaction ID. When
> the other transaction completes (and releases its ExclusiveLock on its
> ID), the waiter is released.
>
> Offhand I think this is only used to implement waits associated with
> SELECT FOR UPDATE row locking --- all other locks are on tables or
> table-like objects.

What about two processes updating the same row? I thougth
PostGres locks the row in this case and this would also
be reflected as an entry in pg_locks with mode
ExclusiveLock.

michael

--
Michael Schulte, Solaris Kernel Development, Sun Microsystems

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Andreas Schmitz 2003-02-28 09:16:29 Re: Still a bug in the VACUUM ??? !!!
Previous Message Tom Lane 2003-02-28 04:24:11 Re: Transaction isolation and UNION queries