| From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | Ian Barwick <barwick(at)gmx(dot)net> |
| Cc: | Ed Baer <Ed(at)always24x7(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: PostgreSQL Backup problems with tsearch2 |
| Date: | 2003-11-11 01:45:29 |
| Message-ID: | 3FB03F39.7090802@familyhealth.com.au |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>>Is the problem with backing up and restoring a database which has tsearch2
>>installed and enabled delt with in Version 7.4 of PostgreSQL?
>
>
> If it's the problem with restoring the tsearch2-related functions, then no,
> and I'm not sure whether it's "fixable" (in the sense that a tsearch2 enabled
> database will do a painless dump/restore).
>
> I've had some success by making sure all tsearch2-related functions
> are in their own schema, which I don't dump or use for restoring;
> before restoring I recreate the schema from a script, then reload
> the other schemas. There's a slight gotcha though which I can't recall
> offhand. I'll try and write it up next time I got through the process.
What I did is I edited my dump and removed all the tsearch stuff. Then
I copied the tsearch2.sql just after the CREATE DATABASE statement.
This ensured that all the dependencies work fine.
Since then, I think PostgreSQL's default dump order has just worked.
The main situation that causes complete breakage is:
CREATE TABLE...
CREATE TYPE...
ALTER TABLE / ADD COLUMN newtype
Basically, any object that you can add dependencies to after it has been
initially created can cause problems. eg. all the CREATE OR REPLACE
commands, etc.
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Mauger | 2003-11-11 01:58:40 | Re: [HACKERS] Proposal: psql force prompting on notty |
| Previous Message | Tatsuo Ishii | 2003-11-11 01:33:44 | Re: Experimental patch for inter-page delay in VACUUM |