Re: migrate data 6.5.3 -> 8.3.1 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: migrate data 6.5.3 -> 8.3.1
Date
Msg-id 29918.1219076257@sss.pgh.pa.us
Whole thread Raw
In response to Re: migrate data 6.5.3 -> 8.3.1  (alexander lunyov <lan@zato.ru>)
Responses Re: migrate data 6.5.3 -> 8.3.1  (alexander lunyov <lan@zato.ru>)
List pgsql-hackers
alexander lunyov <lan@zato.ru> writes:
> Tom Lane wrote:
>>> I wonder if you need these self defined aggregates at all, most or all 
>>> of them are in 8.3 already.
>> 
>> They aren't "self defined" in 6.5 either.  

> So i can't just delete those AGGREGATEs?

>> I think what is happening
>> is that he's trying to force a 7.x pg_dump to dump from the 6.5 server
>> (with -i no doubt), and it's just tremendously confused about what's
>> what and what it should dump.

> These errors occurs when i'm trying to restore dump from 6.5 on 8.3.

I took a trip down memory lane looking at the 6.5 pg_dump code ...
the way it decides whether an object is built-in or user-defined is
by looking at its OID, using the rule that any OID less than template1's
OID must be built in.  Which actually ought to mostly work.  I speculate
that template1 got dropped and recreated sometime during this
installation's history.  That would still not produce the observed
symptoms, except that the "OID" comparisons are all done using signed
integer comparisons.  So if the new template1 had an OID past 2 billion,
pretty much everything would look like it was user-defined.  Were you
getting bogus duplicate type and operator definitions as well as aggregates?

Can we see the results of "select oid, datname from pg_database" in
the 6.5 installation?  There might be some other candidate you could
rename to template1 to get this to work better.

Of course, since you got the data migrated you might not care anymore.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: SeqScan costs
Next
From: Tom Lane
Date:
Subject: Re: SeqScan costs