Re: [GENERAL] Restoring a Databases that features tserach2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fischer Ulrich <ulrich(dot)fischer(at)aerodynamics(dot)ch>
Cc: a(dot)schmitz(at)cityweb(dot)de, pgsql-admin(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Restoring a Databases that features tserach2
Date: 2004-04-22 15:32:57
Message-ID: 7243.1082647977@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-general

Fischer Ulrich <ulrich(dot)fischer(at)aerodynamics(dot)ch> writes:
> Tom Lane wrote:
>> This is certainly not going to work because the dump from the old
>> database will already have all the tsearch2 objects, not to mention
>> whatever setup_ge_ispell.sql may create. You should get rid of steps
>> 3 and 3a.

> Get rid of Step 3 and 3a produces Errors in Step 4 like:
> ERROR: type "tsvector" does not exist

Yeah, not surprising if you used ALTER TABLE to add a tsvector column
to a table created before you'd loaded tsearch2 into the database.
The dump will create the objects in the wrong order.

This whole class of problems should be gone in 7.5, since CVS-tip
pg_dump understands dependencies properly. As a short-term workaround
I'd suggest using "pg_dump -Fc db" as the source data and manually
adjusting the load order with pg_restore's -L option. The
separate-schema-and-data approach is not very good since it's a lot
slower to load large databases that way.

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2004-04-22 15:46:13 Re: Transaction log file screwed up
Previous Message JC Jan Christensen 2004-04-22 15:16:42 INITDB-error - end-of-copy marker error

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2004-04-22 15:41:43 Re: Missing OID rant
Previous Message scott.marlowe 2004-04-22 14:59:17 Re: 7.3.4 on Linux: UPDATE .. foo=foo+1 degrades massivly