Re: RI_FKey_check: foreign key constraint blocks parallel

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.