On Mon, Sep 21, 2009 at 3:07 AM, Boszormenyi Zoltan <z...@cybertec.at> wrote: > Jeff Janes írta: >> >> Maybe I am biased in this because I am primarily thinking about how I >> would use such a feature, rather than how Hans-Juergen intends to use >> it, and maybe those uses differ. Hans-Juergen, could you describe >> your use case a little bit more? Who do is going to be getting these >> time-out errors, the queries run by the web-app, or longer running >> back-office queries? And when they do get an error, what will they do >> about it? > > Our use case is to port a huge set of Informix apps, > that use SET LOCK MODE TO WAIT N; > Apparently Tom Lane was on the opinion that > PostgreSQL won't need anything more in that regard.
Will statement_timeout not suffice for that use case? I understand that they will do different things, but do not understand why those difference are important. Are there "invisible" deadlocks that need to be timed out, while long running but not dead-locking queries that need to not be timed out? I guess re-running a long-running query is never going to succeed unless the execution plan is improved, while rerunning a long-blocking query is expected to succeed eventually? Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
