Fwd: [HACKERS] RI_FKey_check: foreign key constraint blocks parallel

(Just noticed that this was sent to hackers, but -general would probably
get to more of the people who might want to see it)

On Fri, 15 Nov 2002, Stephan Szabo wrote:

> On Fri, 15 Nov 2002, Manfred Koizar wrote:
>
> > On Wed, 13 Nov 2002 14:22:51 -0800 (PST), Stephan Szabo
> > <sszabo(at)megazone23(dot)bigpanda(dot)com> wrote:
> > >Right now, I know that it has a hole that lets through invalid data
> >
> > Stephan, your patch has been posted to -general (Subject: Re:
> > [GENERAL] Help..Help...). Is this version still valid?
>
> I have a newer version of it on my machine, but I was still sending out
> that version of the patch. :( Thanks for letting me know before even more
> people got a version that was broken. :)
>
> For anyone working with the patch, you need to fix the lines below as
> noted by Manfred. This is mostly unrelated to the hole mentioned in the
> quoted message above (it's a bug that with the bug you actually partially
> fill the hole but instead deadlock). I wonder if there were any other
> stupdities in there.
>
> > > void
> > > heap_mark4fk_lock_acquire(Relation relation, HeapTuple tuple) {
> > > [...]
> > > /* try to find the list for the table in question */
> > This part of the patch works, if the list
> > (a) is initially empty or
> > (b) already contains relid or
> > (c) starts with a table > relid.
> >
> > > while (ptr!=NULL) {
> > > if (relid>ptr->table) {
> > > ptr=ptr->next;
> > > oldptr=ptr;
> > // AFAICT above two lines should be swapped ...
> > > }
> > > else
> > > break;
> > > }
> >
> > ... otherwise
> > (d) if the new relid is to be inserted between two existing entries,
> > we get two items pointing to each other
> > (e) if the new relid is > the last table in the list, we lose the
> > whole list.