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,
Hans
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 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]
-- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/2952/30706 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
