=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <postgres(at)cybertec(dot)at> writes:
> i have attached a patch implementing NO WAIT with the help of a GUC
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
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
In response to
- NO WAIT ... at 2004-02-18 17:14:15 from Hans-Jürgen Schönig
pgsql-hackers by date
|Next:||From: Jeremy Smith||Date: 2004-02-18 18:06:32|
|Subject: Re: CHAR(n) always trims trailing spaces in 7.4|
|Previous:||From: Tom Lane||Date: 2004-02-18 17:27:29|
|Subject: Re: [SQL] 7.4 - FK constraint performance |
pgsql-patches by date
|Next:||From: Bruce Momjian||Date: 2004-02-18 18:23:25|
|Subject: Re: NO WAIT ...|
|Previous:||From: Tom Lane||Date: 2004-02-18 17:42:28|
|Subject: Re: Doing psql's lexing with flex |