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

--
Greg


On 11 May 2009, at 11:18, Hans-Juergen Schoenig <postgres@cybertec.at>
wrote:

> hello greg,
>
> the thing with statement_timeout is a little bit of an issue.
> you could do:
>   SET statement_timeout TO ...;
>   SELECT FOR UPDATE ...
>   SET statement_timeout TO default;
>
> this practically means 3 commands.

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


>
> 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?


>
> imagine something like that (theoretical example):
>
>   SELECT ...
>      FROM
>      WHERE x > ( SELECT some_very_long_thing)
>   FOR UPDATE ...;
>
> some operation could run for ages without ever taking a single,
> relevant lock here.
> so, you don't really get the same thing with statement_timeout.
>
>   regards,
>
>      hans
>
>
>
>
> Greg Stark wrote:
>> Can't you to this today with statement_timeout? Surely you do want
>> to rollback the whole transaction or at least the subtransaction if
>> you have error handling.
>>
>
>
>
>
> --
> Cybertec Schönig & Schönig GmbH
> Professional PostgreSQL Consulting, Support, Training
> Gröhrmühlgasse 26, A-2700 Wiener Neustadt
> Web: www.postgresql-support.de
>