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

Re: Wrong FOR UPDATE lock type

From: Jan Wieck <janwieck(at)Yahoo(dot)com>
To: "Mikheev, Vadim" <vmikheev(at)sectorbase(dot)com>
Cc: "'Jan Wieck'" <janwieck(at)yahoo(dot)com>, PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Wrong FOR UPDATE lock type
Date: 2000-12-04 19:18:25
Message-ID: 200012041918.OAA17820@jupiter.jw.home (view raw or flat)
Thread:
Lists: pgsql-hackers
Mikheev, Vadim wrote:
> >     I'm  about  99.666667% sure that the lock type choosen in the
> >     FOR UPDATE case (line  511  of  parse_relation.c)  should  be
> >     RowExclusiveLock  instead  of  RowShareLock.   Actually I get
> >     "Deadlock risk" debug messages when selecting FOR UPDATE  and
> >     then really UPDATE.
>
> http://www.postgresql.org/users-lounge/docs/6.5/user/x3116.htm
>
> RowShareLock
> Acquired by SELECT FOR UPDATE and LOCK TABLE for IN ROW SHARE MODE
> statements.
>
> Conflicts with ExclusiveLock and AccessExclusiveLock modes.

    Tom,

    IIRC  the  "Deadlock risk" debug message is from you. I think
    it must get a little smarter. IMHO an application that want's
    to  UPDATE  something  in  a  transaction but must SELECT the
    row(s) first to do it's own calculation on them,  should  use
    SELECT FOR UPDATE. Is that debug output really appropriate in
    this case (it raises from  RowShareLock  to  RowExclusiveLock
    because  of  the  UPDATE  of the previous FOR UPDATE selected
    row)?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #



In response to

Responses

pgsql-hackers by date

Next:From: Thomas LockhartDate: 2000-12-04 19:31:27
Subject: [Fwd: Re: [CORE] Going Beta on Monday ...]
Previous:From: Jan WieckDate: 2000-12-04 19:04:51
Subject: Re: [SQL] Rules with Conditions: Bug, or Misunderstanding

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