On Sun, Sep 27, 2009 at 1:31 PM, Robert Haas robertmh...@gmail.com wrote:
As to #3, that's obviously gotta be fixed. If we're to further
consider this patch for this CommitFest, that fixing needs to happen
pretty soon.
Since it has been 6 days since I posted this and more than 2 weeks
since
On Mon, Sep 21, 2009 at 6:07 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
Jeff Janes írta:
On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan z...@cybertec.at
mailto:z...@cybertec.at wrote:
Boszormenyi Zoltan írta:
Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
Robert Haas robertmh...@gmail.com writes:
As to #1, personally, I think it's quite useful. The arguments that
have been made that lock_timeout is redundant with statement_timeout
don't seem to me to have much merit.
...
As to #2, I was initially thinking dedicated syntax would be better
On Wed, 2009-09-23 at 10:58 -0700, Josh Berkus wrote:
So, while some people have asserted that a lock_timeout GUC would
allow
users to retrofit older applications to time out on locks, I just
don't
see that being the case. You'd have to refactor regardless, and if
you're going to, just add
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
Jeff,
Will statement_timeout not suffice for that use case?
Well, currently statement_timeout doesn't affect waiting for locks.
And as a DBA, I don't think I'd want the same timeout for executing
queries as for waiting for a lock.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Josh Berkus j...@agliodbs.com writes:
Jeff,
Will statement_timeout not suffice for that use case?
Well, currently statement_timeout doesn't affect waiting for locks.
Sure it does.
And as a DBA, I don't think I'd want the same timeout for executing
queries as for waiting for a lock.
Well,
Tom,
Well, that's exactly what Jeff is questioning. How big is the use-case
for that exactly?
I think that it's not necessary to have a 2nd GUC, but for a different
reason than argued.
For the applications I work on, I tend to set statement_timeout to
something high designed just to catch
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Jeff,
Will statement_timeout not suffice for that use case?
Well, currently statement_timeout doesn't affect waiting for locks.
Sure it does.
And as a DBA, I don't think I'd want the same timeout for
Jeff Janes wrote:
Will statement_timeout not suffice for that use case?
we tried to get around it without actually touching the core but we
really need this functionality.
patching the core here is not the primary desire we have. it is all
about modeling some functionality which was truly
Jeff Janes írta:
On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan z...@cybertec.at
mailto:z...@cybertec.at wrote:
Boszormenyi Zoltan írta:
Okay, we implemented only the lock_timeout GUC.
Patch attached, hopefully in an acceptable form.
Documentation included in
Jeff Janes írta:
On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan z...@cybertec.at
mailto:z...@cybertec.at wrote:
Boszormenyi Zoltan írta:
Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
The vague consensus for syntax options was that the GUC
I think that if the use case for a GUC is to set it, run a single very
specific statement, and then unset it, that is pretty clear evidence that
this should not be a GUC in the first place.
+1
Plus, do we really want another GUC?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
On Mon, Sep 21, 2009 at 1:32 PM, Josh Berkus j...@agliodbs.com wrote:
I think that if the use case for a GUC is to set it, run a single very
specific statement, and then unset it, that is pretty clear evidence that
this should not be a GUC in the first place.
+1
Plus, do we really want
Robert Haas escribió:
Of course, I don't want:
- GUCs that I'm going to set, execute one statement, and the unset
(and this likely falls into that category).
- GUCs that are poorly designed so that it's not clear, even to an
experienced user, what value to set.
- GUCs that exist only to
On Mon, Sep 21, 2009 at 3:14 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
Of course, I don't want:
- GUCs that I'm going to set, execute one statement, and the unset
(and this likely falls into that category).
- GUCs that are poorly designed so that it's not
Alvaro Herrera alvhe...@commandprompt.com writes:
Perhaps we'd benefit from a way to set a variable for a single query;
Yeah, particularly if it allows us to fend off requests for random
one-off features to accomplish the same thing ...
WITH ( SET query_lock_timeout = 5s ) SELECT ...
Of
On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
Boszormenyi Zoltan írta:
Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
The vague consensus for syntax options was that the GUC
'lock_timeout' and WAIT [N] extension (wherever NOWAIT
is allowed) both
On Sat, Sep 19, 2009 at 4:17 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
Boszormenyi Zoltan írta:
Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
The vague consensus for syntax options was that the GUC
On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
Boszormenyi Zoltan írta:
Okay, we implemented only the lock_timeout GUC.
Patch attached, hopefully in an acceptable form.
Documentation included in the patch, lock_timeout
works the same way as
Boszormenyi Zoltan írta:
Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
The vague consensus for syntax options was that the GUC
'lock_timeout' and WAIT [N] extension (wherever NOWAIT
is allowed) both should be implemented.
Behaviour would be that N seconds timeout should be
Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
The vague consensus for syntax options was that the GUC
'lock_timeout' and WAIT [N] extension (wherever NOWAIT
is allowed) both should be implemented.
Behaviour would be that N seconds timeout should be
applied to every lock that the
Bruce Momjian írta:
Hans-Juergen Schoenig wrote:
hello everybody,
from my side the goal of this discussion is to extract a consensus so
that we can go ahead and implement this issue for 8.5.
our customer here needs a solution to this problem and we have to come
up with something which
Boszormenyi Zoltan wrote:
The vague consensus for syntax options was that the GUC
'lock_timeout' and WAIT [N] extension (wherever NOWAIT
is allowed) both should be implemented.
Behaviour would be that N seconds timeout should be
applied to every lock that the statement would take.
In
Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
The vague consensus for syntax options was that the GUC
'lock_timeout' and WAIT [N] extension (wherever NOWAIT
is allowed) both should be implemented.
Behaviour would be that N seconds timeout should be
applied to every lock that the
Boszormenyi Zoltan wrote:
Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
The vague consensus for syntax options was that the GUC
'lock_timeout' and WAIT [N] extension (wherever NOWAIT
is allowed) both should be implemented.
Behaviour would be that N seconds timeout should be
Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
The vague consensus for syntax options was that the GUC
'lock_timeout' and WAIT [N] extension (wherever NOWAIT
is allowed) both should be implemented.
Behaviour would be that
Hans-Juergen Schoenig wrote:
hello everybody,
from my side the goal of this discussion is to extract a consensus so
that we can go ahead and implement this issue for 8.5.
our customer here needs a solution to this problem and we have to come
up with something which can then make it into
hello everybody,
from my side the goal of this discussion is to extract a consensus so
that we can go ahead and implement this issue for 8.5.
our customer here needs a solution to this problem and we have to come
up with something which can then make it into PostgreSQL core.
how shall we
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.
--
Greg
On 11 May 2009, at 10:26, Hans-Juergen Schoenig postg...@cybertec.at
wrote:
hello everybody,
i would like to propose
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
2009/5/11 Hans-Juergen Schoenig postg...@cybertec.at
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;
Why not extend the SET instruction to allow configuration parameters
--On 11. Mai 2009 06:38:44 -0300 Lucas Brito luca...@gmail.com wrote:
Why not extend the SET instruction to allow configuration parameters to
be set only in the duration of the transaction or the next n commands?
It's already there: see SET LOCAL.
--
Thanks
Bernd
--
Sent via
--
Greg
On 11 May 2009, at 11:18, Hans-Juergen Schoenig postg...@cybertec.at
wrote:
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
I tend to think there should be protocol level support for options
like this but that would require buy-in from the interface writers.
how would you do it?
if you support it on the protocol level, you still need a way to allow
the user to tell you how ...
i would see WAIT for DELETE,
Hans-Juergen Schoenig postg...@cybertec.at writes:
i would like to propose an extension to our SELECT FOR UPDATE mechanism.
especially in web applications it can be extremely useful to have the
chance to terminate a lock after a given timeframe.
I guess my immediate reactions to this are:
1.
Boszormenyi Zoltan z...@cybertec.at writes:
Would the lock_timeout work for all to be acquired locks individually,
or all of them combined for the statement? The individual application
of the timeout for every locks individually wouldn't be too nice.
I think the way you're describing would be
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
Would the lock_timeout work for all to be acquired locks individually,
or all of them combined for the statement? The individual application
of the timeout for every locks individually wouldn't be too nice.
I think the way
Boszormenyi Zoltan z...@cybertec.at writes:
Tom Lane írta:
I think the way you're describing would be both harder to implement
and full of its own strange traps.
Why?
Well, for one thing: if I roll back a subtransaction, should the lock
wait time it used now no longer count against the
Hi,
Tom Lane írta:
Hans-Juergen Schoenig postg...@cybertec.at writes:
i would like to propose an extension to our SELECT FOR UPDATE mechanism.
especially in web applications it can be extremely useful to have the
chance to terminate a lock after a given timeframe.
I guess my
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
Tom Lane írta:
I think the way you're describing would be both harder to implement
and full of its own strange traps.
Why?
Well, for one thing: if I roll back a subtransaction, should the lock
wait time
2009/5/11 Boszormenyi Zoltan z...@cybertec.at:
Does statement_timeout counts against subtransactions as well? No.
If a statement finishes before statement_timeout, does it also decrease
the possible runtime for the next statement? No. I was talking about
locks acquired during one statement.
hello tom ...
the reason for SELECT FOR UPDATE is very simple:
this is the typical lock obtained by basically every business
application if written properly (updating a product, whatever).
the problem with NOWAIT basically is that if a small transaction holds
a a lock for a subsecond, you
Greg Stark írta:
2009/5/11 Boszormenyi Zoltan z...@cybertec.at:
Does statement_timeout counts against subtransactions as well? No.
If a statement finishes before statement_timeout, does it also decrease
the possible runtime for the next statement? No. I was talking about
locks acquired
2009/5/11 Hans-Jürgen Schönig postg...@cybertec.at:
i agree that a GUC is definitely an option.
however, i would say that adding an extension to SELECT FOR UPDATE, UPDATE
and DELETE would make more sense form a usability point of view (just my
0.02 cents).
I kinda agree with this. I believe
But more generally, what you are proposing seems largely duplicative
with statement_timeout. The only reason I can see for a
lock-wait-specific timeout is that you have a need to control the
length of a specific wait and *not* the overall time spent. Hans
already argued upthread why he wants
Josh Berkus írta:
But more generally, what you are proposing seems largely duplicative
with statement_timeout. The only reason I can see for a
lock-wait-specific timeout is that you have a need to control the
length of a specific wait and *not* the overall time spent. Hans
already argued
Robert Haas robertmh...@gmail.com writes:
I kinda agree with this. I believe Tom was arguing upthread that any
change of this short should touch all of the places where NOWAIT is
accepted now, and I agree with that. But having to issue SET as a
separate statement and then maybe do another
Tom,
My point is that I don't believe the scenario where you say that you
know exactly how long each different statement in your application
should wait and they should all be different. What I do find credible
is that you want to set a policy for all the lock timeouts. Now
think about what
Josh Berkus j...@agliodbs.com writes:
I can see Zoltan's argument: for web applications, it's important to
keep the *total* wait time under 50 seconds for most users (default
browser timeout for most is 60 seconds).
And why is that only about lock wait time and not about total execution
On 5/11/09 4:25 PM, Tom Lane wrote:
Josh Berkusj...@agliodbs.com writes:
I can see Zoltan's argument: for web applications, it's important to
keep the *total* wait time under 50 seconds for most users (default
browser timeout for most is 60 seconds).
And why is that only about lock wait time
51 matches
Mail list logo
