Yes, it can be dangerous. I am aware of that.
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 have done some testing with a real world application. As far as I can see it did not have an impact on other internals (at least not when used cleverly).
SELECT FOR UPDATE NO WAIT should be added as well because it might be useful to Oracle <-> compatibility.
Do you think it would help to reduce the GUCs flexibility by reducing the lock levels a user is allowed to define?

Best regards,


Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:

i have attached a patch implementing NO WAIT with the help of a GUC variable.

I consider this patch incredibly dangerous, as it affects *every* lock
taken, including system internal lock acquisitions.

I think it might be reasonable to implement a no-wait option on explicit
LOCK TABLE commands, and perhaps we could do it for SELECT FOR UPDATE
as well.  But it should not be done in a way that breaks internal lock

Also, I don't care for the idea of a GUC variable affecting this.
See recent discussions about how changing fundamental semantics via
easily-changed GUC values is risky.  If we're going to do it we should
add syntax to the LOCK command so that apps explicitly request it.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/2952/30706 or +43/664/233 90 75,,

---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?

Reply via email to