Re: Dumpall without OID

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

In response to

Responses

Browse pgsql-general by date

  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?