Re: PostgreSQL Backup problems with tsearch2

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: Raw Message | Whole Thread | 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

In response to

Browse pgsql-hackers by date

  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