Re: pg_upgrade: What is changed?

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: pg_upgrade: What is changed?
Дата
Msg-id 44EC4170.8090204@sun.com
обсуждение исходный текст
Ответ на Re: pg_upgrade: What is changed?  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: pg_upgrade: What is changed?
Re: pg_upgrade: What is changed?
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Tricky bugs in concurrent index build
Следующее
От: Alban Hertroys
Дата:
Сообщение: Re: [GENERAL] Queries joining views