Re: pg_upgrade: What is changed?

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_upgrade: What is changed?
Date: 2006-08-23 11:52:16
Message-ID: 44EC4170.8090204@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2006-08-23 11:54:08 Re: Tricky bugs in concurrent index build
Previous Message Greg Stark 2006-08-23 11:48:15 Re: Tricky bugs in concurrent index build