From: | "Carlos Oliva" <carlos(at)pbsinet(dot)com> |
---|---|
To: | "'Michael Fuhr'" <mike(at)fuhr(dot)org> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: ExclusiveLock without a relation in pg_locks |
Date: | 2006-02-23 18:23:36 |
Message-ID: | 200602231824.NAA24243@pbsi.pbsinet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Yes. I am seeing that situation often in our database.
The query field of pg_stat_activity is SELECT ..., not SLECT UPDATE or
UPDATE or INSERT or DELETE. I was expecting the query to say something like
SLECT UPDATE or something like that. Also the query seems to have just
columns in the select statement; not functions.
I will look further into these queries in case that they are using
functions.
-----Original Message-----
From: pgsql-general-owner(at)postgresql(dot)org
[mailto:pgsql-general-owner(at)postgresql(dot)org] On Behalf Of Michael Fuhr
Sent: Thursday, February 23, 2006 1:09 PM
To: Carlos Oliva
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] ExclusiveLock without a relation in pg_locks
On Thu, Feb 23, 2006 at 11:08:07AM -0500, Carlos Oliva wrote:
> Thank you very much for your answer. I think that I am seeing those self
> transaction id locks as "ExclusiveLocks"
>
> Would you expect to see an "ExclusiveLock" with a query of type Select
(not
> Select Update or Update or Insert)?
Not in general, unless perhaps the select called a function that
acquired such a lock. The Concurrency Control chapter in the
documentation has a section on lock types and the commands that
acquire them:
http://www.postgresql.org/docs/8.1/interactive/explicit-locking.html
Are you just curious or are you seeing such a situation?
--
Michael Fuhr
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
From | Date | Subject | |
---|---|---|---|
Next Message | Rodrigo Sakai | 2006-02-23 18:34:36 | Temporal Databases |
Previous Message | A. Kretschmer | 2006-02-23 18:15:18 | Re: Limitations : Number of ... |