Re: INSERT/SELECT and excessive foreign key checks - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: INSERT/SELECT and excessive foreign key checks
Date
Msg-id 20070821145527.GK2355@alvh.no-ip.org
Whole thread Raw
In response to Re: INSERT/SELECT and excessive foreign key checks  (Lodewijk Vöge <lvoege@gmail.com>)
Responses Re: INSERT/SELECT and excessive foreign key checks  (Lodewijk Vöge <lvoege@gmail.com>)
List pgsql-hackers
Lodewijk Vöge escribió:
> On 19-aug-2007, at 12:38, Tom Lane wrote:
>
>> An additional problem with your proposal is that it fails to consider
>> other changes that might be happening concurrently -- eg, what if some
>> other backend deletes a source row after you copy it, and commits before
>> you do?
>
> then the patch indeed failed, but when I change it to check those carried 
> over FKs also once, it catches it correctly.
>
> are there other such issues? or is this kind of optimization not going in 
> no matter what?

It might go in if it's correct.  If you have an answer to all the
objections then there's no reason not to include it.  But I must admit I
didn't understand what was your answer to the above objection; care to
rephrase?

-- 
Alvaro Herrera                 http://www.amazon.com/gp/registry/CTMLCN8V17R4
"On the other flipper, one wrong move and we're Fatal Exceptions"
(T.U.X.: Term Unit X  - http://www.thelinuxreview.com/TUX/)


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: tsearch2 patch status report
Next
From: Tom Lane
Date:
Subject: Re: tsearch2 patch status report