Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

>
> I tend to think there should be protocol level support for options
> like this but that would require buy-in from the interface writers.
>
>

how would you do it?
if you support it on the protocol level, you still need a way to allow
the user to tell you how ...
i would see WAIT for DELETE, UPDATE and SELECT FOR UPDATE.
did you have more in mind?

>>
>> the killer argument, however, is that the lock might very well happen
>> ways after the statement has started.
>
> Sure. But Isn't the statement_timeout behaviour what an application
> writer would actually want? Why would he care how long some sub-part
> of the statement took? Isn't an application -you used the example of a
> web app - really concerned with its response time?
>
>

no, for a simple reason: in this case you would depend ways too much in
other tasks. some other reads which just pump up the load or some
nightly cronjobs would give you timeouts which are not necessarily
related to locking. we really want to protect us against some "LOCK
TABLE IN ACCESS EXCLUSIVE MODE" - i am not looking for a solution which
kills queries after some time (we have that already). i want protect
myself against locking issues.
this feature is basically supported by most big vendor (informix,
oracle, just to name a few). i am proposing this because i have needed
it for a long time already and in this case it is also needed for a
migration project.

hans

--
Cybertec Schönig & Schönig GmbH
Professional PostgreSQL Consulting, Support, Training
Gröhrmühlgasse 26, A-2700 Wiener Neustadt
Web: www.postgresql-support.de