Re: COPY errors when trying to convert from 7.4.19 to 8.3.1

Поиск
Список
Период
Сортировка
От Geoffrey
Тема Re: COPY errors when trying to convert from 7.4.19 to 8.3.1
Дата
Msg-id 481A1FF1.6080700@serioustechnology.com
обсуждение исходный текст
Ответ на Re: COPY errors when trying to convert from 7.4.19 to 8.3.1  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-admin
Tom Lane wrote:
> Geoffrey <lists@serioustechnology.com> writes:
>> We are trying to test our process for upgrading our database from 7.4.19
>> to 8.3.1.  We are following the instructions for dumping the 7.4.19
>> database from:
>> http://www.postgresql.org/docs/8.3/static/install-upgrading.html
>> ie:
>> /usr/local/pg83/bin/pg_dumpall -h master -p 5434 |gzip > dump.gz
>> Create a new 8.3.1 cluster as follows:
>> /usr/local/pg83/bin/initdb -D /data/pgsql/master83
>> Load the data into the new cluster:
>> gunzip < dump.gz |/usr/local/pg83/bin/psql -d postgres
>
>> We know we have some old data in the database that does not meet current
>> criteria, thus we are seeing errors such as:
>
>> ERROR:  insert or update on table "aaccess" violates foreign key
>> constraint "$1"
>> DETAIL:  Key (code)=(CFSAVAUS000) is not present in table "arates".
>
>> What baffles us is, that although we get these errors, the data is still
>> being inserted in to the table, in this case, the aaccess table.
>
> Well, the insert has already happened: the error is actually coming out
> when the dump script tries to do ALTER TABLE ADD CONSTRAINT FOREIGN KEY.
> (The message is perhaps a bit misleading if you don't notice which
> command caused it.)
>
> What this looks like to me is a misordering of the dump operations such
> that we're trying to do the ALTER on aaccess after loading its data,
> but before loading arates's data.  In theory 8.3's pg_dump should
> avoid such mistakes, but it's possible you've got a case that fools it.
>
> Anyway, the first thing you should do to investigate is to check exactly
> what's the order of operations in the script and which command is
> causing the failure.  If the data involved is too large to make it
> convenient to eyeball the dump script with an editor, you might try
> running the dump script with log_statement = all so you can see just the
> SQL commands in the postmaster log.

It's manageable, so I'll take an eye at it.  As always, thanks for your
insights Tom.

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin

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

Предыдущее
От: Shane Ambler
Дата:
Сообщение: Re: How to configure Postgre 8.2 to put the data base in a especific directory
Следующее
От: Geoffrey
Дата:
Сообщение: Re: COPY errors when trying to convert from 7.4.19 to 8.3.1