Re: Debugging deadlocks

On Sun, Mar 27, 2005 at 01:37:44AM -0700, Michael Fuhr wrote:
[]
> The current implementation supports only
> exclusive row-level locks (SELECT FOR UPDATE), but I think Alvaro
> might be working on shared row-level locks for a future release.

Hmm ... are you saying that SELECT FOR UPDATE exquires an exclusive lock
on the row in question in the sense that it conflicts with other
*readers* trying to access that row? The documentation would appear to
say otherwise:

-- snip --
Row-level locks do not affect data querying; they block writers to the
same row only. To acquire a row-level lock on a row without actually
modifying the row, select the row with SELECT FOR UPDATE.
-- snap --

(from: http://www.vitavoom.com/postgresql-docs/explicit-locking.html)

and

-- snip --
A row-level lock on a specific row is automatically acquired when the
row is updated (or deleted or marked for update). The lock is held until
the transaction commits or rolls back. Row-level locks do not affect
data querying; they block writers to the same row only.
-- snap --

(from: http://www.postgresql.org/docs/7.4/static/explicit-locking.html)

but then I don't understand the original poster's problem at all, since
his queries are only *reading* the referenced tables??

Regards,

Frank