Hi,
Simon Riggs wrote:
> In practice, many lock contention situations are caused by long running
> idle transactions, so having a deadlock detector be able to resolve a
> situation by deciding that an idle xact is actually in some kind of wait
> state would be very useful.
Hm.. so you'd abort the transaction that's been idle the longest? Is
that really the one you want to abort in every case?
We currently abort the one which is checking for deadlocks, right?
That's a pretty random pick, then. And randomization might have benefits
here (namely giving all kinds of transaction, whether interactive or
automated, the same chance of surviving a deadlock). I'm not sure
whether or not this is a good or required thing, though.
Allow me to also point out the related requirement of several
replication solutions to gather information about such a deadlock or
maybe even control the choice of which transaction to abort. See
http://wiki.postgresql.org/wiki/ClusterFeatures#A_standard_way_to_get_global_deadlock_information
> Some people have asked for a idle-in-transaction-timeout. I would be
> more inclined to have a settable time after which an idle-in-transaction
> session that blocks an active lock requestor can be aborted by the
> deadlock detector as a way of resolving a lock wait. Idle-in-transaction
> sessions that don't hold any locks aren't the same kind of annoyance,
> though there may be other reasons to remove them.
Aha, yes I see. That sounds more controllable (and should probably
default to no timeout).
Regards
Markus Wanner