Re: Row level locking

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: Carlos Benkendorf <carlosbenkendorf(at)yahoo(dot)com(dot)br>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Row level locking
Date: 2005-10-14 05:00:53
Message-ID: 20051014050053.GA50432@winnie.fuhr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Oct 13, 2005 at 08:32:28AM +0000, Carlos Benkendorf wrote:
> I agree that select for update will be the best choice but it
> does not have any effect with insert statements.
>
> if you try the following sequence in two different transactions,
> the select for update will succeed but the insert will be blocked.
>
> begin transaction;
> select employee_id from employees where employee_id=3 for update;
> insert into employees values (3,33);

In this example it seems that you want to know in advance whether
a row that might not be visible to you or that might not even exist
yet will cause some subsequent operation to block. Such a check
is subject to a race condition: the situation could change after
the check but before you act on the result.

If you simply don't want to block for very long then you could use
a statement timeout. If you're using 8.0 or later then you could
use a savepoint to roll back a timed-out operation without aborting
the entire transaction.

If that doesn't help then perhaps you could give us a higher-level
description of the problem you're trying to solve.

--
Michael Fuhr

In response to

Browse pgsql-general by date

  From Date Subject
Next Message srikanth potluri 2005-10-14 06:36:26 installation guide
Previous Message pratap chandran 2005-10-14 04:47:11 Urgent : Postgresql installation error somebody help