Re: URGENT: referential integrity problem

Stephan Szabo wrote:

> On Wed, 29 Jan 2003, pginfo wrote:
>
> > Stephan Szabo wrote:
> >
> > > If you still have the dump you last used to import to 7.3 you might want
> > > to see if a new load of that data has integrity problems.
> >
> > As I checked the problem exists also in the dump from 7.2.3 ( before it was on
> > 7.2.1).I have this file backedup.
> > By importing in 7.3.1 the pg do not reported errors.
> > Only for example:
> > If I import data in oracle after importin it start integrity check and only if no
> > errors exeists it
> > commits data. And I was very supprised that pg do not check this thinks.
>
> It's a speed of load issue.  I think 7.3's dumps use alter table and will
> check.  Probably it'll eventually become optional.

Hmm, as default option pg_dump on 7.3.1 do not check for reference integrity.I do not
know about any option for this case.
Which is the option?

If (for the same data ) on 7.3.1 I make pg_dump and after it import, pg do not report
any errors, do not stop and inserts the same data.
For me it is big problem (no mather if I spear time my import) that I am not sure for
data integrity.
Pls., if this option do not exists in 7.3 include it in dev. list for 7.4. I think it
is very important.

>
>
> > > In any case,
> > > since most of the bugs that I know about went the other direction
> > > (disallowing valid changes), I'm still interested in seeing if we can find
> > > out what happened.  The table definitions for both tables and the
> > > constraint definition would be useful, and if you happen to know whether
> > > you were likely to have changed the pk row before inserting the fk rows or
> > > if you had the fk rows and then changed the pk row since that'd narrow
> > > down the possible places to look.
> >
> >   I have also interest to detect and fix the problem. We plane ( and did it) to
> > use pg for many projects and we need stable db.
> >
> > In case you are interested I can give you access to the test server and you will
> > be able to see
> > the problem alone (It will take a little time to configure the server, but it is
> > not problem).
> >
> > In any case I have interest first to fix the problem and second to fix the data.
>
> Well, the problem is that if it's in the dump then we've probably lost any
> of the information to track down what happened from the data (actually,
> probably vacuum would have destroyed it as well anyway, but...) but with a
> little info I can at least try to go over the code.
>
> The schema portion of the dump and any info on your usage patterns for
> modifying the tables would probably help (you can send it to just me if
> you don't want it on list).

Ok, I will send it to you.

>  Also, if you use any functions to modify the
> tables, there were some bugs that did get fixed between 7.2 and 7.3
> regarding foreign keys in that case, although I'd thought that they all
> were of the variety of disallowing valid sequences.

No, we do not have any functions for table modify.

regards,
ivan