Re: pg_migrator and an 8.3-compatible tsvector data type - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_migrator and an 8.3-compatible tsvector data type
Date
Msg-id 22236.1243622662@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_migrator and an 8.3-compatible tsvector data type  (Josh Berkus <josh@agliodbs.com>)
Responses Re: pg_migrator and an 8.3-compatible tsvector data type  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> It would be nice to have pg_migrator handle this, especially if we could 
> do it in parallel.  Then we just have to warn users that migrating a 
> database with tsvector columns takes significantly longer.  That is,

> 1) do rest of catalog swap and link/copy of objects.
> 2) mark all tsvector columns as 83_tsvector and add new tsvector type
>     (these columns will be unusable for queries)
> 3) bring up database
> 4) search for all 83_tsvector columns
> 5) do ALTER TABLE on each of these columns, in parallel, up to a 
> configuration setting (default 3).

pg_migrator is already emitting a script that is intended to be run
after conversion, to handle REINDEXing of incompatible indexes.  That
could easily be made to do ALTER TYPE on old tsvector columns too, no?

The parallel bit is pie in the sky and should not be considered even
for a millisecond during this release cycle.  Save it for 8.5, or
suggest to people that they manually cut the script apart if they're
desperate to have that.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type
Next
From: Heikki Linnakangas
Date:
Subject: Re: Clean shutdown and warm standby