Thread: Error during a dump (ts_selectivity, not found)
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
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
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
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
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 >
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? > 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
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
On Wed, Jan 19, 2011 at 3:00 PM, Ahmed Ossama <ahmed@aossama.net> 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.
Ahmed Ossama <ahmed@aossama.net> 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