vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| > >> first: thanks for your fast answer. > >> > >> if had found it in the manual but there is only a short clause about > >> this topic: > >> > >> "Abort any statement that takes over the specified number of > >> milliseconds. A value of zero (the default) turns off the limitation. " > >> > >> ( by the way in my config file is it set to zero by default and that > >> means that it will be wait without a timeout. > >> #statement_timeout = 0 # 0 is disabled, in milliseconds > >> ) > >> > >> so but i'm not sure, doesn't it mean that all statements that take > >> longer than this time will be abort? > >> if it is so, that isn't a solution for this problem because than i > >> can't make a "big" request anymore. > > > > You can change it during a session "set statement_timeout=2000" > > > yes, but that isn't a certain event that say that the data is locked! > also the network for example can determine different timeouts. > and also i don't know the working time for each request before. > that isn't a solution for me. i will open a "please wait, while the data > is locked" - window, if the data is locked. > > and it seems as if this should be a problem with postgres :-( I am not a big fan of twiddling statement_timeout, it creates more problems than it solves. Thomas, select...for update is not really designed to hold pessimistic locks, only in-transaction locks. For example, it is considered (very) bad practices to hold a lock while waiting for input from the user. Have you looked at contrib\userlock? With it, you can simulate pessimistic locks with a non-blocking result code. Merlin ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly |