> > > The only way PG could apply reasonable timeouts would be for the
> > > application to dictate them,
> >
> > That is exactly what we are talking about here.
>
> No. You wrote elsewhere that the application sets "30 seconds" and
> leaves it. But that 30 seconds doesn't have any applicat
On Wed, Apr 18, 2001 at 09:39:39PM -0400, Bruce Momjian wrote:
> > On Wed, Apr 18, 2001 at 07:33:24PM -0400, Bruce Momjian wrote:
> > > > What might be a reasonable alternative would be a BEGIN timeout:
> > > > report failure as soon as possible after N seconds unless the
> > > > timer is reset, s
> On Wed, Apr 18, 2001 at 07:33:24PM -0400, Bruce Momjian wrote:
> > > What might be a reasonable alternative would be a BEGIN timeout: report
> > > failure as soon as possible after N seconds unless the timer is reset,
> > > such as by a commit. Such a timeout would be meaningful at the
> > >
On Wed, Apr 18, 2001 at 07:33:24PM -0400, Bruce Momjian wrote:
> > What might be a reasonable alternative would be a BEGIN timeout: report
> > failure as soon as possible after N seconds unless the timer is reset,
> > such as by a commit. Such a timeout would be meaningful at the
> > database-
> What might be a reasonable alternative would be a BEGIN timeout: report
> failure as soon as possible after N seconds unless the timer is reset,
> such as by a commit. Such a timeout would be meaningful at the
> database-interface level. It could serve as a useful building block
> for appl
On Wed, Apr 18, 2001 at 09:54:11AM +0200, Zeugswetter Andreas SB wrote:
> > > In short, I think lock timeout is a solution searching in vain for a
> > > problem. If we implement it, we are just encouraging bad application
> > > design.
> >
> > I agree with Tom completely here.
> >
> > In any re
[ Charset ISO-8859-1 unsupported, converting... ]
> > One idea Tom had was to make it only active in a transaction,
> > so you do:
> >
> > BEGIN WORK;
> > SET TIMEOUT TO 10;
> > UPDATE tab SET col = 3;
> > COMMIT
> >
> > Tom is concerned people will do the SET and forget to RESE
[ Charset ISO-8859-1 unsupported, converting... ]
> > This is the real reason why I've been holding out for restricting the
> > feature to a specific LOCK TABLE statement: if it's designed that way,
> > at least you know which lock you are applying the timeout to, and have
> > some chance of being
> One idea Tom had was to make it only active in a transaction,
> so you do:
>
> BEGIN WORK;
> SET TIMEOUT TO 10;
> UPDATE tab SET col = 3;
> COMMIT
>
> Tom is concerned people will do the SET and forget to RESET
> it, causing all queries to be affected by the timeout.
> This is the real reason why I've been holding out for restricting the
> feature to a specific LOCK TABLE statement: if it's designed that way,
> at least you know which lock you are applying the timeout to, and have
> some chance of being able to estimate an appropriate timeout.
As I pointed be
> > It is not something that makes anything unrelyable or less robust.
>
> How can you argue that? The presence of a lock timeout *will* make
> operations fail that otherwise would have succeeded; moreover that
> failure will be pretty unpredictable (at least from the point of view
> of the app
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> It is not something that makes anything unrelyable or less robust.
How can you argue that? The presence of a lock timeout *will* make
operations fail that otherwise would have succeeded; moreover that
failure will be pretty unpredictable (at
> > In short, I think lock timeout is a solution searching in vain for a
> > problem. If we implement it, we are just encouraging bad > application
> > design.
>
> I agree with Tom completely here.
>
> In any real-world application the database is the key component of a
> larger system: the w
> Timeouts are a system-level mechanism that to be useful must refer to
> system-level events that are far above anything that PG knows about.
> The only way PG could apply reasonable timeouts would be for the
> application to dictate them, but the application can better implement
> them itse
On Tue, Apr 17, 2001 at 12:56:11PM -0400, Tom Lane wrote:
> In short, I think lock timeout is a solution searching in vain for a
> problem. If we implement it, we are just encouraging bad application
> design.
I agree with Tom completely here.
In any real-world application the database is the k
> > The timeout will be useful to let the client or user decide
> > on an alternate course of action other that killing his
> > application (without the need for timers or threads in the
> > client program).
>
> This assumes (without evidence) that the client has a good
> idea of what the timeout
> > Added to TODO:
> > * Add SET parameter to timeout if waiting for lock too long
>
> I repeat my strong objection to any global (ie, affecting all locks)
> timeout. Such a "feature" will have unpleasant consequences.
But LOCK TABLE T IN ROW EXCLUSIVE MODE WITH TIMEOUT X will not give
requ
Michael Ansley <[EMAIL PROTECTED]> writes:
> Sorry for my forgetfulness (and a search through geocrawler didn't turn up
> anything useful), but what was the problem with something like NOWAIT?
> e.g.: SELECT * FROM a FOR UPDATE NOWAIT;
> where, if the required lock could not be obtained immediatel
Title: RE: AW: [HACKERS] timeout on lock feature
Sorry for my forgetfulness (and a search through geocrawler didn't turn up anything useful), but what was the problem with something like NOWAIT?
e.g.: SELECT * FROM a FOR UPDATE NOWAIT;
where, if the required lock could not be obt
> > The timeout will be useful to let the client or user decide on an
> > alternate course of action other that killing his application (without
> > the need for timers or threads in the client program).
>
> This assumes (without evidence) that the client has a good idea of what
> the timeout li
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> The timeout will be useful to let the client or user decide on an
> alternate course of action other that killing his application (without
> the need for timers or threads in the client program).
This assumes (without evidence) that the client
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> The timeout will be useful to let the client or user decide on an
> alternate course of action other that killing his application (without
> the need for timers or threads in the client program).
Okay, let's take a close look at this assumptio
> > Added to TODO:
> > * Add SET parameter to timeout if waiting for lock too long
>
> I repeat my strong objection to any global (ie, affecting all locks)
> timeout. Such a "feature" will have unpleasant consequences.
Except that other people like myself, see those consequences
as a plea
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Added to TODO:
> > > * Add SET parameter to timeout if waiting for lock too long
> >
> > I repeat my strong objection to any global (ie, affecting all locks)
> > timeout. Such a "feature" will have unpleasant consequences.
>
> I envisioned:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I envisioned:
> SET TIMEOUT TO 10;
> UPDATE tab SET col = 3;
> RESET TIMEOUT
> Can't we get that work work properly? Let the timeout only apply to the
> 'tab' table and none of the others.
As Henryk has implemented it, it WON'T only
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Added to TODO:
> * Add SET parameter to timeout if waiting for lock too long
I repeat my strong objection to any global (ie, affecting all locks)
timeout. Such a "feature" will have unpleasant consequences.
regards, tom l
> > I envisioned:
>
> > SET TIMEOUT TO 10;
> > UPDATE tab SET col = 3;
> > RESET TIMEOUT
>
> > Can't we get that work work properly? Let the timeout only
> apply to the
> > 'tab' table and none of the others.
>
> As Henryk has implemented it, it WON'T only apply to the 'tab' tabl
Added to TODO:
* Add SET parameter to timeout if waiting for lock too long
>
> > I was thinking SET because UPDATE does an auto-lock.
>
> Optimal would imho be a SET that gives a maximum amount of time in seconds
> the client is willing to wait for any lock. But I
> I was thinking SET because UPDATE does an auto-lock.
Optimal would imho be a SET that gives a maximum amount of time in seconds
the client is willing to wait for any lock. But I liked the efficiency of Henryk's
code.
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I can imagine some
> The appropriate way to do this given a LOCK TABLE option would be like
>
> BEGIN;
> LOCK TABLE foo IN ROW EXCLUSIVE MODE WITH TIMEOUT n;
> UPDATE foo SET ...;
> COMMIT;
>
> which restricts the scope of the timeout behavior to just the specific
> lock that the user is th
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was thinking SET because UPDATE does an auto-lock.
Not to mention a ton of implicit locks acquired on various system tables
during parsing/planning. You really want auto timeout on all of those?
I sure don't.
The appropriate way to do this given a L
I was thinking SET because UPDATE does an auto-lock.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I can imagine some people wanting this. However, 7.1 has new deadlock
> > detection code, so I would you make a 7.1 version and send it over. We
> > can get it into 7.2.
>
> I object strongly
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I can imagine some people wanting this. However, 7.1 has new deadlock
> detection code, so I would you make a 7.1 version and send it over. We
> can get it into 7.2.
I object strongly to any such "feature" in the low-level form that
Henryk proposes, b
I can imagine some people wanting this. However, 7.1 has new deadlock
detection code, so I would you make a 7.1 version and send it over. We
can get it into 7.2. I think we need a SET variable, and it should
default to OFF.
Good idea. Thanks.
> Hi,
>
> I implement additional server functio
If you can't handle the SET variable stuff, we can do it over here.
Thanks.
> Hi,
>
> I implement additional server functionality. Currently (v7.0.3), executing
> SQL update statement on the same
> row from inside two different processess results in blocking second process
> to the end of tran
Hi,
I implement additional server functionality. Currently (v7.0.3), executing
SQL update statement on the same
row from inside two different processess results in blocking second process
to the end of transaction in
the first one. In real OLTP application second process can't wait too long.
Afte
Hi,
i implement additional server functionality. Currently (v7.0.3), executing
SQL update statement on the same
row from inside two different processess results in blocking second process
to the end of transaction in the first one.
In real OLTP application second process can't wait too long. Afte
37 matches
Mail list logo
