Re: Foreign key wierdness - Mailing list pgsql-hackers

From Dave Page
Subject Re: Foreign key wierdness
Date
Msg-id 03AF4E498C591348A42FC93DEA9661B8857F@mail.vale-housing.co.uk
Whole thread Raw
In response to Foreign key wierdness  ("Dave Page" <dpage@vale-housing.co.uk>)
Responses Re: Foreign key wierdness  (Didier Moens <Didier.Moens@dmb.rug.ac.be>)
List pgsql-hackers

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 20 January 2003 16:08
> To: Dave Page
> Cc: PostgreSQL Hackers Mailing List; Didier Moens
> Subject: Re: [HACKERS] Foreign key wierdness
>
>
> "Dave Page" <dpage@vale-housing.co.uk> writes:
> > Thing is Tom, this issue can be reproduced *every* time,
> without fail.
>
> And have you vacuumed or analyzed yet?  Or possibly you are
> short an index or two (you really need indexes on both the
> referencing and referenced columns).

Didier?

> > I've been looking at his for some time now (couple of weeks
> or more),
> > and the only thing I can find is the SELECT ... FOR UPDATE in the
> > PostgreSQL logs that I quoted. These exactly follow *every* fkey
> > creation, and are definately not issued by pgAdmin.
>
> No, I told you: those are the internal verification query (it
> comes from RI_FKey_check_ins(), if you want to look).

Sorry, brain hiccup.

> If you really think the schema qualification has something to
> do with it, try issuing the ADD FOREIGN KEY command manually
> in psql, with and without schema name.

Well to be honest I'm having a hard time believing it, but having looked
at this in some depth, it's the only thing that the 2 versions of
pgAdmin are doing differently. Even the PostgreSQL logs agree with that.
I'm relying on Didier for test results though as I don't have a test
system I can use for this at the moment.

But it gives us something to try - Didier can you create a new database
please, and load the data from 2 tables. VACUUM ANALYZE, then add the
foreign key in psql using the syntax 1.4.2 uses. Then drop the database,
and load exactly the same data in the same way, VACUUM ANALYZE again,
and create the fkey using the qualified tablename syntax.

Thanks, Dave.


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Foreign key wierdness
Next
From: "Dave Page"
Date:
Subject: Re: Foreign key wierdness