From: | Girts Laudaks <laudaksg(at)gmail(dot)com> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Dumpall without OID |
Date: | 2011-01-28 12:54:18 |
Message-ID: | 4D42BC7A.1080405@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Well, seems that everything is OK. There are no OIDs used from the
application side but they still appear in the database tables, this was
what made the confusion.
Thanks,
G.
On 2011.01.27. 21:33, Adrian Klaver wrote:
> On 01/27/2011 04:52 AM, Girts Laudaks wrote:
>> Hi,
>>
>> What could be the possible damage if a database is migraged without the
>> -o (OID) option? Integrity of data?
>
> User OIDs are deprecated,so the main problem is whether you are
> currently using them as foreign keys. If you do not specify the -o
> switch and have OIDs specifically defined for a table(not the default)
> then new ones will be generated when the data is restored. If your
> schema/app depend on the old numbers then it would be a problem.
>
>> What are the options to solve this problem if it is migrated this way?
>> Shouldn't pg_dumpall work like an exact copy of db?
>> What could have gone wrong if only these commands were used?
>>
>> pg_dumpall -v -U postgres | gzip > /var/lib/pgsql/dump.data.gz
>> gunzip -c /var/lib/pgsql/dump.data.gz | psql -U postgres >>
>> /tmp/import.log
>>
>> They were used to migrate from PG8.4 to PG9
>>
>> Regards,
>> Girts
>>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Kemanetzis | 2011-01-28 12:57:45 | Re: Select query ignores index on large table |
Previous Message | Dimitri Fontaine | 2011-01-28 12:47:16 | Re: How best to load modules? |