Tom,
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?= <postgres@cybertec.at> 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 majordomo@postgresql.org
--
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
