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-
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
> 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 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
12 matches
Mail list logo
