--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
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 have
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
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.
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 for the
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
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 agree with Tom
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 common
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 of minor
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 postmaster
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 Oracle spell this?
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 NO WAIT.
--
Tatsuo
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
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 a variable.)
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 data
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 the LOCK
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 regex
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 specific SQL
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
19 matches
Mail list logo
