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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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