Hans-J�rgen Sch�nig wrote:
> 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 ...
There was, but we have seen some concerns about GUC controlling too much
since we added it, I think.
> >>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.
Well, you already allow the user to control the level of locks he wants
to timeout on, so it is merely an issue of setting the default for your
second GUC.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
