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