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