Re: URGENT: referential integrity problem

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: URGENT: referential integrity problem
Дата
Msg-id 20030129104800.N12532-100000@megazone23.bigpanda.com
обсуждение исходный текст
Ответ на Re: URGENT: referential integrity problem  (pginfo <pginfo@t1.unisoftbg.com>)
Список pgsql-general
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.

> > 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).  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.



В списке pgsql-general по дате отправления:

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: index on timestamp performance
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Installing PG 7.3.1 on Solaris 8