Re: Prototype: In-place upgrade v02 - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: Prototype: In-place upgrade v02
Date
Msg-id 48C5284C.8010305@sun.com
Whole thread Raw
In response to Re: Prototype: In-place upgrade v02  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> Another idea is to create backward compatible AM and put them into separate 
>> library. If these AM will work also with old page structure then there should
>> not be reason for reindexing or index page conversion after upgrade.
> 
> I don't think that'd be real workable.  It would require duplicating all
> the entries for that AM in pg_opfamily, pg_amop, etc.  Which we could do
> for the built-in entries, I suppose, but what happens to user-defined
> operator classes?

When catalog upgrade will be performed directly, user-defined op classes should 
stay in the catalog. But question is what's happen with regproc records and if 
all functions will be compatible with a new server ... It invokes idea that we 
need stable API for operator and data types implementation. All datatype which 
will use only this API, then can be used on new PostgreSQL versions without 
recompilation.

> At least for the index changes proposed so far for 8.4, it seems to me
> that the best solution is to mark affected indexes as not "indisvalid"
> and require a post-conversion REINDEX to fix 'em.  Obviously a better
> solution would be nice later, but we have to avoid putting huge amounts
> of work into noncritical problems, else the whole feature is just not
> going to get finished.

Agree.
Zdenek



-- 
Zdenek Kotala              Sun Microsystems
Prague, Czech Republic     http://sun.com/postgresql



pgsql-hackers by date:

Previous
From: "Greg Stark"
Date:
Subject: Re: [PATCH] Cleanup of GUC units code
Next
From: tomas@tuxteam.de
Date:
Subject: Re: [PATCH] Cleanup of GUC units code