Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
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.
--
Greg
On 11 May 2009, at 10:26, Hans-Juergen Schoenig <postgres@cybertec.at>
wrote:
Show quoted text
hello everybody,
i would like to propose an extension to our SELECT FOR UPDATE
mechanism.
especially in web applications it can be extremely useful to have
the chance to terminate a lock after a given timeframe.
i would like to add this functionality to PostgreSQL 8.5.the oracle syntax is quite clear and easy to use here:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_10002.htm#i2126016
informix should behave pretty much the same way.
are there any arguments from hackers' side against this feature?many thanks,
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--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: 4A07E14C.3030906@cybertec.atReference msg id not found: 4A07E14C.3030906@cybertec.at
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.
the killer argument, however, is that the lock might very well happen
ways after the statement has started.
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
2009/5/11 Hans-Juergen Schoenig <postgres@cybertec.at>
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;
Why not extend the "SET" instruction to allow configuration parameters to be
set only in the duration of the transaction or the next "n" commands?
--
Lucas Brito