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

From Lodewijk Vöge
Subject Re: INSERT/SELECT and excessive foreign key checks
Date
Msg-id FF90C38D-0939-4C55-B73C-67516051D5E6@gmail.com
Whole thread Raw
In response to Re: INSERT/SELECT and excessive foreign key checks  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: INSERT/SELECT and excessive foreign key checks  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
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?

Lodewijk


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: 8.3 beta testing suggestions welcome
Next
From: Magnus Hagander
Date:
Subject: Re: tsearch2 patch status report