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.
There was discussion and I thought agreement that a GUC was best because
we wouldn't have to add syntax to every command. I think the idea
originally was that we were going to do nowait only on exclusive locks
and not shared ones, which would hopefully reduce system lock cases
where are usually shared ones.
I imagine folks would want it on UPDATE, DELETE, and VACUUM FULL too,
and that's why a GUC makes more sense, rather than littering the syntax
with nowait controls.
Also, I don't see this changing sematics like the regex flavor did.
With that one, we actually had stored data in a table that wouldn't
match a CHECK constraint. This isn't going to affect data validity,
only query success.
--
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
