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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
