Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
От | Hans-Juergen Schoenig |
---|---|
Тема | Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 |
Дата | |
Msg-id | 4A07ED73.3020607@cybertec.at обсуждение исходный текст |
Ответ на | Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 (Greg Stark <greg.stark@enterprisedb.com>) |
Ответы |
Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: