Re: [HACKERS] 'Waiting on lock'

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jaime Casanova" <systemguards(at)gmail(dot)com>, "pgsql-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] 'Waiting on lock'
Date: 2007-09-25 14:56:47
Message-ID: 87tzpin68g.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:

> 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.

To make this explicit, I think the typical scenario where it would make a
difference is where you're running some large job in a plpgsql function. You
might be processing millions of records but want for a single step of that
process to not wait for a lock. You still want to process all the records you
can though.

So for example if you're updating all the user profiles on your system but
don't want to block on any user-profiles which are locked by active users --
especially if you use database locks for user-visible operations which users
can drag out for long periods of time. (Not saying I agree with that design
but there are arguments for it and people do do it)

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Julius Stroffek 2007-09-25 17:25:54 Re: Optimizer hook
Previous Message Simon Riggs 2007-09-25 14:40:14 Re: [HACKERS] 'Waiting on lock'