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

Re: NO WAIT ...

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>,pgsql-patches(at)postgresql(dot)org
Subject: Re: NO WAIT ...
Date: 2004-02-18 18:23:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
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.

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                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to


pgsql-hackers by date

Next:From: Hans-Jürgen SchönigDate: 2004-02-18 18:27:10
Subject: Re: NO WAIT ...
Previous:From: Jeremy SmithDate: 2004-02-18 18:06:32
Subject: Re: CHAR(n) always trims trailing spaces in 7.4

pgsql-patches by date

Next:From: Hans-Jürgen SchönigDate: 2004-02-18 18:27:10
Subject: Re: NO WAIT ...
Previous:From: Tom LaneDate: 2004-02-18 18:06:27
Subject: Re: NO WAIT ...

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