Re: [Xen-devel] [OSSTEST PATCH 1/4] Database locking: Perl: Retry all deadlocks in PostgreSQL

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [OSSTEST PATCH 1/4] Database locking: Perl: Retry all 
deadlocks in PostgreSQL"):
> On Tue, 2015-12-15 at 16:26 +0000, Ian Jackson wrote:
> > +sub need_retry ($$$) {
> > +    my ($jd, $dbh,$committing) = @_;
> > +    return
> > +   $dbh_tests->err()==7 &&
> > +   ($dbh_tests->state =~ m/^40P01/); # DEADLOCK DETECTED
> 
> How come this return value doesn't need to include $committing in some way?

$committing is just there as a fudge for the benefit of SQLite3, which
only fails during COMMIT.  In PostgreSQL we can always tell by the
error code.

> Also, "DEADLOCK DETECTED" presumably only occurs when fighting with some
> other client, as opposed to this client being broken and doing "LOCK A;
> ....; LOCK A"? Or if not we have a retry limit so such code won't just spin
> forever.

Databases (at least PostgreSQL) take care of all that kind of thing:
they will detect the deadlock.  IDK what happens if you try to lock
the same table twice in the same transaction but it will either work
or fail with a deadlock error.  If it fails with a deadlock error
then as you say the retry limit will catch it.

(Deadlocks involving perhaps multiple processes, doing IPC outside the
DB, and with multiple db connections, are not necessarily detectable
by the DB.  But this change does not make that possibility any worse.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel