Re: Lock!

From: Ang Chin Han <angch(at)bytecraft(dot)com(dot)my>
To: Oliver Elphick <olly(at)lfix(dot)co(dot)uk>
Cc: Szabó Péter <matyee(at)westel900(dot)net>, pgsql-admin(at)postgresql(dot)org
Subject: Re: Lock!
Date: 2003-10-15 04:26:39
Message-ID: 3F8CCC7F.6@bytecraft.com.my
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Oliver Elphick wrote:
> You can't.
>
> Quote from the manual:
> So long as no deadlock situation is detected, a transaction
> seeking either a table-level or row-level lock will wait
> indefinitely for conflicting locks to be released. This means it
> is a bad idea for applications to hold transactions open for
> long periods of time (e.g., while waiting for user input).

Unless you set STATEMENT_TIMEOUT:

http://www.postgresql.org/docs/7.3/static/runtime-config.html#RUNTIME-CONFIG-GENERAL

In other words, try:

SET STATEMENT_TIMEOUT=50;
SELECT * FROM foo WHERE foo_id = 1 FOR UPDATE;

That means if another process is locking foo_id = 1 row for more than 50
millisecond after you try to SELECT it FOR UPDATE, you'll get an
error/rollback, and you can then assume it's being used.

Just remember to reset STATEMENT_TIMEOUT to zero or your default before
any slow queries in that transaction.

There was some discussion about emulating (IIRC) Oracle's SELECT .. FOR
UPDATE NOWAIT somewhere in the Postgresql archives. Look them up for
more details.

In response to

  • Re: Lock! at 2003-10-14 16:27:53 from Oliver Elphick

Responses

  • Locks at 2003-10-15 12:45:22 from Greg Spiegelberg
  • Re: Lock! at 2003-10-15 15:26:52 from Tom Lane

Browse pgsql-admin by date

  From Date Subject
Next Message Greg Spiegelberg 2003-10-15 12:45:22 Locks
Previous Message Michelle Murrain 2003-10-15 04:21:55 Re: working with users