Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Date
Msg-id f67928030909230854m47554fdsf297651790a90f37@mail.gmail.com
Whole thread Raw
In response to Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
List pgsql-hackers
On Mon, Sep 21, 2009 at 3:07 AM, Boszormenyi Zoltan <zb@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


pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Hot Standby 0.2.1
Next
From: Tom Lane
Date:
Subject: Re: Hot Standby 0.2.1