> I agree with Tom here. I have used the Oracle NOWAIT feature in the
> past and think it is a great feature IMHO. But when you need to use it,
> you want it to apply very specifically to a single statement. Using a
> sledge hammer when you need a tweezers isn't the right way to go.
Once I h
--On Wednesday, February 18, 2004 13:56:14 -0500 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Tom Lane wrote:
The question is whether we should have a GUC variable to control no
waiting on locks or add NO WAIT to specific SQL commands.
Does anyone want to vote _against_ the GUC idea for nowait lock
> > This is missing the necessary adjustments in backend/nodes/ (copy and
> > equal funcs). Also the NOWAIT keyword must be added to the list of
> > nonreserved keywords near the bottom of gram.y.
>
> Thanks for the review. I'll work on this.
Here is the revised patch.
--
Tatsuo Ishii
==
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > Here is the patch I promised (against current).
>
> This is missing the necessary adjustments in backend/nodes/ (copy and
> equal funcs). Also the NOWAIT keyword must be added to the list of
> nonreserved keywords near the bottom of gram.y.
Thanks f
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Here is the patch I promised (against current).
This is missing the necessary adjustments in backend/nodes/ (copy and
equal funcs). Also the NOWAIT keyword must be added to the list of
nonreserved keywords near the bottom of gram.y.
Here is the patch I promised (against current). Regression tests all
passed. One thing I have not checked is the doc(lock.sgml). For some
reason I failed to install docbook V4.2 (I have working docbook V3.1
though), and I couldn't test the correctness of the file. Also, it
would be nice if some one
It seems "NOWAIT" is the winner...
--
Tatsuo Ishii
> Oracle uses "NOWAIT" so we should go for that one.
>
> Regards,
>
> Hans
>
>
>
> Tatsuo Ishii wrote:
> > If "NOWAIT" is the choice, I could live with it. If there's no
> > objection, I will go with "NOWAIT", not "N
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> If "NOWAIT" is the choice, I could live with it. If there's no
>> objection, I will go with "NOWAIT", not "NO WAIT".
> How about "WITHOUT WAIT", which is like many of our other commands?
The first question in my mind is "exactly how does Orac
If "NOWAIT" is the choice, I could live with it. If there's no
objection, I will go with "NOWAIT", not "NO WAIT".
How about "WITHOUT WAIT", which is like many of our other commands?
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaste
If "NOWAIT" is the choice, I could live with it. If there's no
objection, I will go with "NOWAIT", not "NO WAIT".
--
Tatsuo Ishii
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > LOCK TABLE table NO WAIT is OK for 7.5? If ok, I will make patches
> > against current with some docs changes.
>
> Dept
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> LOCK TABLE table NO WAIT is OK for 7.5? If ok, I will make patches
> against current with some docs changes.
Dept of minor gripes: can we do this without turning "NO" into a
keyword? Even as a nonreserved word, I think that would be annoying.
"no" is a c
Yes, I think it looks good.
---
Tatsuo Ishii wrote:
> LOCK TABLE table NO WAIT is OK for 7.5? If ok, I will make patches
> against current with some docs changes.
> --
> Tatsuo Ishii
>
> > > Tatsuo Ishii wrote:
> > > >>I ag
On Thu, 2004-02-19 at 11:01, Bruce Momjian wrote:
> Zeugswetter Andreas SB SD wrote:
> >
> > > > The question is whether we should have a GUC variable to control no
> > > > waiting on locks or add NO WAIT to specific SQL commands.
> > > >
> > > > Does anyone want to vote _against_ the GUC idea fo
> > I personally think a wait period in seconds would be more useful.
> > Milli second timeouts tend to be misused with way too low values
> > in this case, imho.
>
> I understand, but GUC lost the vote. I have updated the TODO list to
> indicate this. Tatsuo posted a patch to add NO WAIT to th
> I vote for the GUC. Imho it is not comparable to the "autocommit" case,
> since it does not change the way your appl needs to react (appl needs to
> react to deadlock already).
Wrote one program a while ago that was very time sensitive. By the time
deadlock detection had been kicked off, the dat
Zeugswetter Andreas SB SD wrote:
>
> > > The question is whether we should have a GUC variable to control no
> > > waiting on locks or add NO WAIT to specific SQL commands.
> > >
> > > Does anyone want to vote _against_ the GUC idea for nowait locking. (We
> > > already have two voting for such
> > The question is whether we should have a GUC variable to control no
> > waiting on locks or add NO WAIT to specific SQL commands.
> >
> > Does anyone want to vote _against_ the GUC idea for nowait locking. (We
> > already have two voting for such a variable.)
>
> I vote against. We got bit
> Tatsuo Ishii wrote:
> >>I agree with Tom here. I have used the Oracle NOWAIT feature in the
> >>past and think it is a great feature IMHO. But when you need to use it,
> >>you want it to apply very specifically to a single statement. Using a
> >>sledge hammer when you need a tweezers isn't
Tatsuo Ishii wrote:
I agree with Tom here. I have used the Oracle NOWAIT feature in the
past and think it is a great feature IMHO. But when you need to use it,
you want it to apply very specifically to a single statement. Using a
sledge hammer when you need a tweezers isn't the right way to g
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
The question is whether we should have a GUC variable to control no
waiting on locks or add NO WAIT to specific SQL commands.
That's only a minor part of the issue. The major problem I have with
the patch is that it affects *all* locks, in
TODO updated:
< * Add GUC variable to prevent waiting on locks
> * Add NO WAIT option to various SQL commands
---
Barry Lind wrote:
> I agree with Tom here. I have used the Oracle NOWAIT feature in the
>
Larry Rosenman wrote:
-- Start of PGP signed section.
>
>
> --On Wednesday, February 18, 2004 13:56:14 -0500 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> > Tom Lane wrote:
>
> > The question is whether we should have a GUC variable to control no
> > waiting on locks or add NO WAIT to specifi
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The question is whether we should have a GUC variable to control no
> > waiting on locks or add NO WAIT to specific SQL commands.
>
> That's only a minor part of the issue. The major problem I have with
> the patch is that it affects
I agree with Tom here. I have used the Oracle NOWAIT feature in the
past and think it is a great feature IMHO. But when you need to use it,
you want it to apply very specifically to a single statement. Using a
sledge hammer when you need a tweezers isn't the right way to go.
thanks,
--Barry
Bruce Momjian wrote:
The question is whether we should have a GUC variable to control no
waiting on locks or add NO WAIT to specific SQL commands.
Does anyone want to vote _against_ the GUC idea for nowait locking. (We
already have two voting for such a variable.)
If there is no one except Tom, w
> The question is whether we should have a GUC variable to control no
> waiting on locks or add NO WAIT to specific SQL commands.
>
> Does anyone want to vote _against_ the GUC idea for nowait locking. (We
> already have two voting for such a variable.)
I vote against. We got bit by both the reg
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The question is whether we should have a GUC variable to control no
> waiting on locks or add NO WAIT to specific SQL commands.
That's only a minor part of the issue. The major problem I have with
the patch is that it affects *all* locks, including syst
Tom Lane wrote:
> =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> > The problem with adding NO WAIT to specific commands is that is
> > inheritly unflexible. I think this is why the community has agreed on
> > implementing it based on GUC.
>
> I recall no such agreement ..
28 matches
Mail list logo
