From: | "Thomas F(dot) O'Connell" <tfo(at)sitening(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PgSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: SELECT Generating Row Exclusive Locks? |
Date: | 2005-12-01 05:08:03 |
Message-ID: | 483A120B-E66E-4D2E-A21F-BDC184A388C9@sitening.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Nov 30, 2005, at 10:52 PM, Tom Lane wrote:
> "Thomas F. O'Connell" <tfo(at)sitening(dot)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)
From | Date | Subject | |
---|---|---|---|
Next Message | surabhi.ahuja | 2005-12-01 05:10:51 | Re: postgres log file |
Previous Message | Jochen Wiedmann | 2005-12-01 05:04:32 | Re: undefined behaviour for sub-transactions? |