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

Re: NO WAIT ...

From: Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: NO WAIT ...
Date: 2004-02-18 18:27:10
Message-ID: 4033AE7E.1040705@cybertec.at (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom,

Yes, it can be dangerous. I am aware of that.
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 have done some testing with a real world application. As far as I can 
see it did not have an impact on other internals (at least not when used 
cleverly).
SELECT FOR UPDATE NO WAIT should be added as well because it might be 
useful to Oracle <-> compatibility.
Do you think it would help to reduce the GUCs flexibility by reducing 
the lock levels a user is allowed to define?

	Best regards,

		Hans



Tom Lane wrote:
> =?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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org


-- 
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/2952/30706 or +43/664/233 90 75
www.cybertec.at, www.postgresql.at, kernel.cybertec.at


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-02-18 18:37:38
Subject: Re: NO WAIT ...
Previous:From: Bruce MomjianDate: 2004-02-18 18:23:25
Subject: Re: NO WAIT ...

pgsql-patches by date

Next:From: Tom LaneDate: 2004-02-18 18:37:38
Subject: Re: NO WAIT ...
Previous:From: Bruce MomjianDate: 2004-02-18 18:23:25
Subject: Re: NO WAIT ...

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