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
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 |