> > That's my fallback position. Obviously, this will lead to false > positives depending on server load. In my case, I'm targeting between
> 30-50 users so its likely to throw timeouts for various reasons other > than locks even though my queries of interest are generally select a > from b where id =3D c type of thing. This is a kludgy solution but its > still better than writing cobol. > > The bigger issue is that a timeout will not return the reason the query > timed out. There are cases where I would like to run a select for > update over a range of records and handle the locked records and > unlocked records differently. A query that could match locked oids vs > the oids I am interested in would be super. I could then aggregate my > select for updates into larger queries and reap massive performance > gains. > > Another way of putting it is this: waiting for your select to timeout is > kind of like parking in Manhattan: you back your car up until you hit > the next car. I would sort of like to, uh, look in the rear view mirror > first. > I see your point. > 1. Can you query if a tuple is locked by another transaction (the > documentation unclearly suggests this can't be done via the pg_lock > view) before executing select for update...? Where did you find this? Regards, Christoph ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org