Re: pg_upgrade: What is changed? - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: pg_upgrade: What is changed?
Date
Msg-id 44EC4170.8090204@sun.com
Whole thread Raw
In response to Re: pg_upgrade: What is changed?  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: pg_upgrade: What is changed?
Re: pg_upgrade: What is changed?
List pgsql-hackers
Martijn van Oosterhout wrote:
> On Wed, Aug 23, 2006 at 10:26:19AM +0200, Zdenek Kotala wrote:
> 
> <snip>
> 
>> 1) BKI - catalog.
>>    c) Some records are changed
>>        action: ???
> 
> They just need to be changed. In principle the datalog needs to be
> updated so it looks like a database initdb'd with the new version.

Yes I agree but The question is if some OID collision should appears for 
example collision between user function created in the 8.1 and build-in 
function in 8.2. There are some changes like this:

! insert OID = 1838 ( numeric_variance 11 10 12 f f t f i 1 1700 "1231" 
_null_ _null_ _null_ numeric_variance - _null_ )

! insert OID = 1838 ( numeric_var_samp 11 10 12 f f t f i 1 1700 "1231" 
_null_ _null_ _null_ numeric_var_samp - _null_ )

Is only renaming or is it different proc?

> 
>> 5) Tuples
>>      question: Does have data types some disk representation?
>>                Does have tupleheader same structure?
> 
> I think only the inet/cidr types changed format this release. Ways to
> handle that have been discussed:
> 
> 1. Have server contain code for old versions under old OID. This was
> mentioned as a possibility.
> 2. ALTER TYPE ALTER TYPE from old to new type, possibly using text as
> intermediary.
> 3. Fiddle with bits on disk (not sure if this is even possible)

It looks like that name is same but data representation is different. 
I'm not sure if possible use same data type names with different OID. I 
think there is unique index. We can rename this type to inet_old, but 
some application should confused. I quickly looked in network.c and It 
looks that data size is same (4 or 16). Option 3 is possible in this 
case and I should be easy to implement it.

Does anybody know what exactly has been changed?

>> 6) Indexes
>>      question: Any changes on disk representation?
>>            Should be possible remove all index before upgrade and 
>>            recreate them on the new version instead upgrade index structure?
> 
> Maybe, maybe not. Why risk it? Just REINDEX the whole database
> afterwards.

Will be possible run REINDEX database with "damaged/old" index data 
structure? For example on inet/cidr index?

Zdenek


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Tricky bugs in concurrent index build
Next
From: Alban Hertroys
Date:
Subject: Re: [GENERAL] Queries joining views