On Nov 30, 2005, at 10:52 PM, Tom Lane wrote:
> "Thomas F. O'Connell" <tfo@sitening.com> 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 the UPDATE with granted = false.
>
> Why would you expect to see that exactly? SELECTs don't block
> UPDATEs.
Mm. I must've been projecting my notion of a problem onto one that
wasn't there, reading (and not thinking) Row Exclusive instead of
Access Exclusive for conflicts. Duh.
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? I recognize that the
pid in pg_locks can be the pid of the server process holding or
awaiting the lock, but I'm seeing granted = true on these, which
implies that the server process corresponding to the SELECT is
holding a Row Exclusive, doesn't it?
--
Thomas F. O'Connell
Database Architecture and Programming
Co-Founder
Sitening, LLC
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005 (cell)
615-469-5150 (office)
615-469-5151 (fax)
