From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: generalized index constraints |
Date: | 2009-09-20 16:31:50 |
Message-ID: | 22968.1253464310@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Sat, 2009-09-19 at 18:00 -0400, Tom Lane wrote:
>> Well, you can't do it *exactly* the same way btree does, but what
>> I would envision is first insert the index tuple and then do a
>> dirty-snapshot search for conflicting tuples. The interlock against
>> conflicting concurrent inserts doesn't need all this new infrastructure
>> you propose; just wait to see if conflicting transactions commit, same
>> as we do now. And I do maintain that that sort of code has a high risk
>> of undetected bugs.
> How do you prevent deadlocks in the following case?
> 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).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2009-09-20 16:44:00 | Re: WIP: generalized index constraints |
Previous Message | Tom Lane | 2009-09-20 16:20:38 | Re: generic copy options |