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