| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hans-Jürgen Schönig <postgres(at)cybertec(dot)at> |
| Cc: | pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: NO WAIT ... |
| Date: | 2004-02-18 18:06:27 |
| Message-ID: | 24637.1077127587@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
=?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
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeremy Smith | 2004-02-18 18:06:32 | Re: CHAR(n) always trims trailing spaces in 7.4 |
| Previous Message | Tom Lane | 2004-02-18 17:27:29 | Re: [SQL] 7.4 - FK constraint performance |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2004-02-18 18:23:25 | Re: NO WAIT ... |
| Previous Message | Tom Lane | 2004-02-18 17:42:28 | Re: Doing psql's lexing with flex |