One way could be -

If the restore you are performing is not very big. Then pg_dump can be taken
with "--inserts" and we can remove "create function <buffercache>" lines
from the output file and restore.

Thanks
VB

On Fri, Sep 30, 2011 at 10:59 AM, Venkat Balaji <venkat.bal...@verse.in>wrote:

> I had faced the same problem 2 days earlier and that was for
> "pg_freespacemap" contrib module.
>
> I did not know the way to ignore these functions and installed THE contrib
> modules and restored. It worked !
>
> I am also looking for a way to ignore these functions.
>
> Thanks
> VB
>
>
> On Fri, Sep 30, 2011 at 8:15 AM, Royce Ausburn <royce...@inomial.com>wrote:
>
>> I'm in the process of testing out Postgres 9.0 for production use.  I've
>> been using it for development on my mac, a build from EnterpriseDB.  We've
>> just installed a 9.0.5 on an Ubuntu (Ubuntu 10.04.3 LTS) machine from a
>> backport from lucid.  There's an existing 8.4.8 postgres install also on
>> that machine, but as far as I'm aware the debs are set up so you can happily
>> have two installs side by side.
>>
>> I've dumped a test DB from my laptop and attempted to restore it on to the
>> ubuntu machine, but I see errors:
>>
>> royce@fishy:~$ createdb test
>> royce@fishy:~$ pg_restore -d test --no-owner test_RTR.pgc
>> pg_restore: [archiver (db)] Error while PROCESSING TOC:
>> pg_restore: [archiver (db)] Error from TOC entry 65; 1255 2194102 FUNCTION
>> pg_buffercache_pages() persona
>> pg_restore: [archiver (db)] could not execute query: ERROR:  could not
>> access file "$libdir/pg_buffercache": No such file or directory
>>    Command was: CREATE FUNCTION pg_buffercache_pages() RETURNS SETOF
>> record
>>    LANGUAGE c
>>    AS '$libdir/pg_buffercache', 'pg_buffercache_...
>>
>>
>> After looking around a bit, my theory on these errors is that my mac has
>> some contrib module installed that adds views to my test database, and those
>> views have been included in the dump.  The contrib module is apparently not
>> installed on the ubuntu machine and hence the restore can't create the
>> views.  Is this theory correct?  If so:
>>
>> - Can these errors be safely ignored? (not ideal, because I'll miss other,
>> real errors)
>> - Is there some simple way I can prevent these views from being emitted as
>> part of the dump?
>> - Is there some simple way I can prevent these views from being restored
>> from a dump that contains them?
>> - Otherwise, how can I purge these contrib modules from my laptop?
>>
>> Otherwise, if my theory is incorrect, any hints as to what it might be?
>>
>> Cheers!
>>
>> --Royce
>>
>> Mac:
>>
>>                                                              version
>>
>> ------------------------------------------------------------------------------------------------------------------------------------
>>  PostgreSQL 9.0.4 on x86_64-apple-darwin, compiled by GCC
>> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664), 64-bit
>> (1 row)
>>
>>
>> Ubuntu box:
>>
>>                                                   version
>>
>> -------------------------------------------------------------------------------------------------------------
>>  PostgreSQL 9.0.5 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.4.real
>> (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 64-bit
>> (1 row)
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>>
>
>

Reply via email to