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

Re: [HACKERS] 'Waiting on lock'

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jaime Casanova <systemguards(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] 'Waiting on lock'
Date: 2007-09-25 14:40:14
Message-ID: 1190731214.4181.499.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-patches
On Tue, 2007-09-25 at 09:16 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > SQLServer and DB2 have more need of this than PostgreSQL, but we do
> > still need it.
> 
> Why?  What does it do that statement_timeout doesn't do better?

If the execution time is negligible, then setting statement_timeout is
the same thing as setting a lock timeout.

If execution time is not negligible, then you may want to tell the
difference between waiting for completion against waiting forever
without doing anything useful at all.

It's also easier to set an all encompassing lock timeout at User level
than it is to set statement_timeout on individual transactions issued by
that user.

Plus, if applications are written using these concepts it is easier to
port them to PostgreSQL.

Not planning to work on this myself, but I think it is a valid TODO.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


In response to

Responses

pgsql-patches by date

Next:From: Gregory StarkDate: 2007-09-25 14:56:47
Subject: Re: [HACKERS] 'Waiting on lock'
Previous:From: Tom LaneDate: 2007-09-25 13:16:53
Subject: Re: [HACKERS] 'Waiting on lock'

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