On Nov 30, 2005, at 11:24 PM, Tom Lane wrote:
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
I guess I'm still somewhat puzzled by the original statement of the
question, then. Why does that particular view of locks occasionally
tie a SELECT to a granted Row Exclusive lock?
You sure it's
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> I guess I'm still somewhat puzzled by the original statement of the
> question, then. Why does that particular view of locks occasionally
> tie a SELECT to a granted Row Exclusive lock?
You sure it's not left over from an update command earli
On Nov 30, 2005, at 10:52 PM, Tom Lane wrote:
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
For instance, if a long SELECT were running against table_foo and an
UPDATE arrived wanting to update table_foo, I would expect to see in
pg_locks an entry corresponding to the SELECT with granted =
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> For instance, if a long SELECT were running against table_foo and an
> UPDATE arrived wanting to update table_foo, I would expect to see in
> pg_locks an entry corresponding to the SELECT with granted = true and
> an entry corresponding to t
On Nov 30, 2005, at 9:22 PM, Thomas F. O'Connell wrote:
I'm monitoring locks using this query:
SELECT pgsa.procpid, pgsa.current_query, pgsa.query_start,
pgc.relname, pgl.mode, pgl.granted
FROM pg_catalog.pg_class pgc, pg_locks AS pgl, pg_stat_activity AS
pgsa
WHERE pgl.pid = pgsa.procpid
I'm monitoring locks using this query:
SELECT pgsa.procpid, pgsa.current_query, pgsa.query_start,
pgc.relname, pgl.mode, pgl.granted
FROM pg_catalog.pg_class pgc, pg_locks AS pgl, pg_stat_activity AS pgsa
WHERE pgl.pid = pgsa.procpid
AND current_query <> ''
AND pgl.relation = pgc.oid
ORDER BY
