Tom Lane wrote:
> =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <postgres@cybertec.at> writes:
>
>>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 recall no such agreement ... when was this exactly? In any case
> Bruce's recent complaints about regex_flavor have altered my opinions
> about GUC variables a bit. They are bigger safety risks than they look,
> especially ones that change semantics and are intended to be modified on
> the fly.
I thought there was an agreement because the GUC version is on the TODO
list. Anyway ...
>>Do you think it would help to reduce the GUCs flexibility by reducing
>>the lock levels a user is allowed to define?
>
>
> I will vote against the patch no matter what, but I agree that it would
> be less dangerous if it were confined to only apply to a limited set of
> lock types.
>
> regards, tom lane
Tom,
I think we should compromise.
We can restrict it to locks which are high enough or higher to make
SELECT FOR UPDATE work.
Of course it would have been nice to have full flexibility but I think
we can have almost the same benefit for lower risk.
How about it? Tom, Bruce - which types of locks do we allow?
I will change the patch then.
Maybe this is the best solution.
Regards,
Hans
--
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
