=?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
attempts.

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]

Reply via email to