Skip site navigation (1) Skip section navigation (2)

Re: NO WAIT ...

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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

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 SmithDate: 2004-02-18 18:06:32
Subject: Re: CHAR(n) always trims trailing spaces in 7.4
Previous:From: Tom LaneDate: 2004-02-18 17:27:29
Subject: Re: [SQL] 7.4 - FK constraint performance

pgsql-patches by date

Next:From: Bruce MomjianDate: 2004-02-18 18:23:25
Subject: Re: NO WAIT ...
Previous:From: Tom LaneDate: 2004-02-18 17:42:28
Subject: Re: Doing psql's lexing with flex

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group