Re: WIP: generalized index constraints

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP: generalized index constraints
Date: 2009-09-20 16:44:00
Message-ID: 1253465040.6983.6.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Sun, 2009-09-20 at 12:31 -0400, Tom Lane wrote:
> > T1: inserts into index
> > T2: inserts into index
> > T1: checks index for conflicts, finds T2
> > T2: checks index for conflicts, finds T1
> You get a deadlock failure, because both transactions will wait for each
> other. So what? It's an error in any case, and you can get a reported
> deadlock in constraint-enforcement scenarios today (conflicting FK
> changes, for instance).

Well, in theory, one of the transactions may have been destined to be
aborted later anyway, and the deadlock detector might kill the wrong
one. But I agree, perhaps I'm over-thinking this one.

Aside: I just realized that my solution to the deadlock problem won't
work with your simpler idea anyway. When reading the index we've long
since lost the information about the specific insert of the specific
command of the other transaction.

I'll make the change.

Jeff Davis

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-09-20 16:45:04 Re: operator exclusion constraints [was: generalized index constraints]
Previous Message Tom Lane 2009-09-20 16:31:50 Re: WIP: generalized index constraints