To whom it may concern,

Please accept my apology if this is not the correct forum, I am new and was unable to find the correct location to send this question.

If you don't wish to answer, could you please direct me to the correct place to ask the question.

Thanks

The question is:

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 not, is there any timeline for this, or is it not considered important since tsearch2 is a contrib component?

I am planning to spend some time rigging up a solution for our implementation, but I am not qualified to create one for general use.

Thanks in advance for your consideration.

ewb

=====================================
Edward W. Baer
Always24x7.com
ed.baer@always24x7.com
=====================================

Search Discussions

  • Ian Barwick at Nov 10, 2003 at 9:54 pm

    On Monday 10 November 2003 20:47, Ed Baer wrote:
    To whom it may concern,

    Please accept my apology if this is not the correct forum, I am new and was
    unable to find the correct location to send this question.

    If you don't wish to answer, could you please direct me to the correct
    place to ask the question.
    Try the OpenFTS-General list:
    http://sourceforge.net/mailarchive/forum.php?forum=openfts-general

    The tsearch2 homepage is here:
    http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/

    (...)
    The question is:

    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.


    Ian Barwick
    barwick@gmx.net
  • Christopher Kings-Lynne at Nov 11, 2003 at 1:45 am

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedNov 10, '03 at 7:47p
activeNov 11, '03 at 1:45a
posts3
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase