=?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]