From: | Christoph Haller <ch(at)rodos(dot)fzk(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | merlin(dot)moncure(at)rcsonline(dot)com |
Subject: | Re: Can pessimistic locking be emulated? |
Date: | 2003-02-27 16:04:24 |
Message-ID: | 3E5E3708.1E8E049E@rodos.fzk.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Ross J. Reedstrom | 2003-02-27 16:13:29 | Re: Simplifying timezone support |
Previous Message | Tom Lane | 2003-02-27 16:00:11 | Re: Free-space-map management thoughts |