Hello all,

I am trying to restore a database on a server from a dump taken from a
different server, but I get the following error:

==============================================================================================================
# pg_restore -Upgsql -d db14 /mnt/backup/__initial_move__/db01_20110114.dump
Password:
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 25; 1255 2299293
FUNCTION tsmatchsel_wrapper(internal, oid, internal, integer) pgsql
pg_restore: [archiver (db)] could not execute query: ERROR: could not
access file "$libdir/ts_selectivity": No such file or directory
Command was: CREATE FUNCTION tsmatchsel_wrapper(internal, oid,
internal, integer) RETURNS double precision
LANGUAGE c
AS '$libdir...
pg_restore: [archiver (db)] could not execute query: ERROR: function
public.tsmatchsel_wrapper(internal, oid, internal, integer) does not exist
Command was: ALTER FUNCTION public.tsmatchsel_wrapper(internal,
oid, internal, integer) OWNER TO pgsql;
pg_restore: [archiver (db)] Error from TOC entry 2189; 2617 2299294
OPERATOR @-@ pgsql
pg_restore: [archiver (db)] could not execute query: ERROR: function
tsmatchsel_wrapper(internal, oid, internal, integer) does not exist
Command was: CREATE OPERATOR @-@ (
PROCEDURE = ts_match_qv,
LEFTARG = tsquery,
RIGHTARG = tsvector,
COMMUTATOR = @-@,
...
pg_restore: [archiver (db)] could not execute query: ERROR: operator
does not exist: tsquery public.@-@ tsvector
Command was: ALTER OPERATOR public.@-@ (tsquery, tsvector) OWNER TO
pgsql;
pg_restore: [archiver (db)] Error from TOC entry 2185; 2617 2299295
OPERATOR @-@ pgsql
pg_restore: [archiver (db)] could not execute query: ERROR: function
tsmatchsel_wrapper(internal, oid, internal, integer) does not exist
Command was: CREATE OPERATOR @-@ (
PROCEDURE = ts_match_vq,
LEFTARG = tsvector,
RIGHTARG = tsquery,
COMMUTATOR = @-@,
...
pg_restore: [archiver (db)] could not execute query: ERROR: operator
does not exist: tsvector public.@-@ tsquery
Command was: ALTER OPERATOR public.@-@ (tsvector, tsquery) OWNER TO
pgsql;

WARNING: errors ignored on restore: 6
==============================================================================================================

I searched for the library ts_selectivity, but all in vain.

Any advice/hint is very much appreciated.

Best Regards,
Ahmed Ossama

Search Discussions

  • Ahmed Ossama at Jan 19, 2011 at 12:57 pm
    Hello all,

    I am trying to restore a database on a server from a dump taken from a
    different server, but I get the following error:

    ==============================================================================================================

    # pg_restore -Upgsql -d db14
    /mnt/backup/__initial_move__/db01_20110114.dump
    Password:
    pg_restore: [archiver (db)] Error while PROCESSING TOC:
    pg_restore: [archiver (db)] Error from TOC entry 25; 1255 2299293
    FUNCTION tsmatchsel_wrapper(internal, oid, internal, integer) pgsql
    pg_restore: [archiver (db)] could not execute query: ERROR: could not
    access file "$libdir/ts_selectivity": No such file or directory
    Command was: CREATE FUNCTION tsmatchsel_wrapper(internal, oid,
    internal, integer) RETURNS double precision
    LANGUAGE c
    AS '$libdir...
    pg_restore: [archiver (db)] could not execute query: ERROR: function
    public.tsmatchsel_wrapper(internal, oid, internal, integer) does not exist
    Command was: ALTER FUNCTION public.tsmatchsel_wrapper(internal,
    oid, internal, integer) OWNER TO pgsql;
    pg_restore: [archiver (db)] Error from TOC entry 2189; 2617 2299294
    OPERATOR @-@ pgsql
    pg_restore: [archiver (db)] could not execute query: ERROR: function
    tsmatchsel_wrapper(internal, oid, internal, integer) does not exist
    Command was: CREATE OPERATOR @-@ (
    PROCEDURE = ts_match_qv,
    LEFTARG = tsquery,
    RIGHTARG = tsvector,
    COMMUTATOR = @-@,
    ...
    pg_restore: [archiver (db)] could not execute query: ERROR: operator
    does not exist: tsquery public.@-@ tsvector
    Command was: ALTER OPERATOR public.@-@ (tsquery, tsvector) OWNER TO
    pgsql;
    pg_restore: [archiver (db)] Error from TOC entry 2185; 2617 2299295
    OPERATOR @-@ pgsql
    pg_restore: [archiver (db)] could not execute query: ERROR: function
    tsmatchsel_wrapper(internal, oid, internal, integer) does not exist
    Command was: CREATE OPERATOR @-@ (
    PROCEDURE = ts_match_vq,
    LEFTARG = tsvector,
    RIGHTARG = tsquery,
    COMMUTATOR = @-@,
    ...
    pg_restore: [archiver (db)] could not execute query: ERROR: operator
    does not exist: tsvector public.@-@ tsquery
    Command was: ALTER OPERATOR public.@-@ (tsvector, tsquery) OWNER TO
    pgsql;

    WARNING: errors ignored on restore: 6
    ==============================================================================================================


    I searched for the library ts_selectivity, but all in vain.

    Any advice/hint is very much appreciated.

    Best Regards,
    Ahmed Ossama
  • Adrian Klaver at Jan 19, 2011 at 2:45 pm

    On Wednesday 19 January 2011 4:57:42 am Ahmed Ossama wrote:
    Hello all,

    I am trying to restore a database on a server from a dump taken from a
    different server, but I get the following error:

    I searched for the library ts_selectivity, but all in vain.

    Any advice/hint is very much appreciated.
    Are you by any chance trying to restore a dump taken from a pre-8.3 server with
    Full Text Search to 8.3+ one? If so in 8.3 Full Text Search moved from being a
    contrib module to being integrated in the server. See here for some tips on how
    to handle if that is the case:
    http://www.postgresql.org/docs/8.3/interactive/textsearch-migration.html
    Best Regards,
    Ahmed Ossama


    --
    Adrian Klaver
    adrian.klaver@gmail.com
  • Tom Lane at Jan 19, 2011 at 4:10 pm

    Adrian Klaver writes:
    On Wednesday 19 January 2011 4:57:42 am Ahmed Ossama wrote:
    I searched for the library ts_selectivity, but all in vain.
    Are you by any chance trying to restore a dump taken from a pre-8.3 server with
    Full Text Search to 8.3+ one? If so in 8.3 Full Text Search moved from being a
    contrib module to being integrated in the server.
    That was never called "ts_selectivity", though. Ahmed must be dealing
    with some third-party extension module. There's no such module in
    pgfoundry, nor has Google ever heard of it, so I'm thinking it was
    privately written code.

    Do you really *need* to restore those objects? If you just ignore the
    errors, you'll get a restore without the custom functions ... but if you
    don't know what they are, maybe you don't need them anymore.

    regards, tom lane
  • Ahmed Ossama at Jan 19, 2011 at 5:45 pm
    Thanks a lot Adrian and Tom.

    Like Tom said, I suspected that I was dealing with a third party extension.

    I have no problems with the restore without them, and the restore goes
    fine, but it stops and the point:
    "WARNING: errors ignored on restore: 6"

    The database is 60GB and it stops at 47GB. So could this extension be
    the reason behind the failure?

    I don't see anything in the logs for more details about this error.

    Best Regards,
    Ahmed Ossama
    On 19/01/2011 18:10, Tom Lane wrote:
    Adrian Klaver<adrian.klaver@gmail.com> writes:
    On Wednesday 19 January 2011 4:57:42 am Ahmed Ossama wrote:
    I searched for the library ts_selectivity, but all in vain.
    Are you by any chance trying to restore a dump taken from a pre-8.3 server with
    Full Text Search to 8.3+ one? If so in 8.3 Full Text Search moved from being a
    contrib module to being integrated in the server.
    That was never called "ts_selectivity", though. Ahmed must be dealing
    with some third-party extension module. There's no such module in
    pgfoundry, nor has Google ever heard of it, so I'm thinking it was
    privately written code.

    Do you really *need* to restore those objects? If you just ignore the
    errors, you'll get a restore without the custom functions ... but if you
    don't know what they are, maybe you don't need them anymore.

    regards, tom lane
  • Tom Lane at Jan 19, 2011 at 7:51 pm

    Ahmed Ossama writes:
    I have no problems with the restore without them, and the restore goes
    fine, but it stops and the point:
    "WARNING: errors ignored on restore: 6"
    Well, those are exactly the errors you showed us, no?
    The database is 60GB and it stops at 47GB.
    Where are you getting those numbers from? In particular, if you're
    comparing on-disk sizes of two installations, maybe the difference is
    just bloat.

    regards, tom lane
  • Ahmed Ossama at Jan 19, 2011 at 8:00 pm

    On 19/01/2011 21:51, Tom Lane wrote:
    Ahmed Ossama<ahmed@aossama.net> writes:
    I have no problems with the restore without them, and the restore goes
    fine, but it stops and the point:
    "WARNING: errors ignored on restore: 6"
    Well, those are exactly the errors you showed us, no?
    Yes, these are the only errors I am getting.
    The database is 60GB and it stops at 47GB.
    Where are you getting those numbers from? In particular, if you're
    comparing on-disk sizes of two installations, maybe the difference is
    just bloat.
    I am comparing between the data/base/xxxx sizes.

    Let me explain how am i comparing, the db administrator first gave me
    the data/ folder of his postgresql installation. Then he gave me the
    dump file, so I am comparing the size of the database after my
    db_restore (when i get the error) with the size of the database in the
    data folder he gave me.

    Am I making an accurate comparison between the original db and the one i
    am trying to dump by comparing their sizes?

    If I am wrong and this size difference is just a bloat (which I hope)
    how do I make sure of that?

    Best Regards,
    Ahmed Ossama
  • Vivek Khera at Jan 19, 2011 at 8:34 pm

    On Wed, Jan 19, 2011 at 3:00 PM, Ahmed Ossama wrote:
    Am I making an accurate comparison between the original db and the one i am
    trying to dump by comparing their sizes?
    No.

    What you might want to do is take a pg_dump of the newly restored DB
    and see if its size is comparable to the size of the original dump.
    These are in a compact format. The on-disk format of the database
    probably has some extra space in it from processing updates and
    deletes over time.

    The other option is to count the number of rows per table and compare those.
  • Tom Lane at Jan 19, 2011 at 8:38 pm

    Ahmed Ossama writes:
    Am I making an accurate comparison between the original db and the one i
    am trying to dump by comparing their sizes? No.
    If I am wrong and this size difference is just a bloat (which I hope)
    how do I make sure of that?
    Maybe count the rows in some of the tables.

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-general @
categoriespostgresql
postedJan 19, '11 at 12:30p
activeJan 19, '11 at 8:38p
posts9
users4
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase