> Well, there is a theoretical chance of deadlock --- not against other
> transactions doing the same thing, since RowShareLock and
> RowExclusiveLock don't conflict, but you could construct deadlock
> scenarios involving other transactions that grab ShareLock or
> ShareRowExclusiveLock. So I don
Jan Wieck <[EMAIL PROTECTED]> writes:
> 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
Jan Wieck <[EMAIL PROTECTED]> writes:
> I'm about 99.67% 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
Mikheev, Vadim wrote:
> > I'm about 99.67% 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
> I'm about 99.67% 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.
