Thread: droplang doesn't completely work?

droplang doesn't completely work?

From
Laurette Cisneros
Date:
In 7.2.1

For database x:
1) On primary sytem:  pg_dump -f x.pgdmp -Fc x
2) On a bkuphost system that has 7.2.2:  createdb -T template0 x  pg_restore -U xuser -h bkuphost -p 5432 -d x -Fc
x.pgdmp
  get error:   pg_restore: [archiver (db)] could not execute query: ERROR:  stat failed on file
'/usr/local/pgsql-7.2/lib/plpgsql':No such file or  directory
 

So, I go back to primary system and
droplang -d x plperl

I do 1) and 2) again. Same ERROR.

So, I go back to primary system again, and for database x:
select proname, probin from pg_proc

and see:
...
plperl_call_handler      | $libdir/plperl 
...

Shouldn't this be gone after I droplang?

I know that if I never did a createlang plperl in a database it is not
there...so why does it stay?  Is this what is still causing the error on
the pg_restore?  Bug?  Work around is to drop this record from the pg_proc
table?

Thanks,

-- 
Laurette Cisneros
The Database Group
(510) 420-3137
NextBus Information Systems, Inc.
www.nextbus.com
----------------------------------
A wiki we will go...



Re: droplang doesn't completely work?

From
Peter Eisentraut
Date:
Laurette Cisneros writes:

> 2) On a bkuphost system that has 7.2.2:
>    createdb -T template0 x
>    pg_restore -U xuser -h bkuphost -p 5432 -d x -Fc x.pgdmp
>
>    get error:
>    pg_restore: [archiver (db)] could not execute query: ERROR:
>    stat failed on file '/usr/local/pgsql-7.2/lib/plpgsql': No such file or
>    directory

Well, is that file (+ .so) there?  What does this path refer to?  Is it
the correct installation location?

> So, I go back to primary system and
> droplang -d x plperl
>
> I do 1) and 2) again. Same ERROR.

Not surprising, since the error refers to plpgsql, not plperl.

> So, I go back to primary system again, and for database x:
> select proname, probin from pg_proc
>
> and see:
> ...
> plperl_call_handler      | $libdir/plperl
> ...
>
> Shouldn't this be gone after I droplang?

Maybe you still have plperlu installed, in which case the language handler
is kept.  Otherwise the answer is yes and you should try to see what
droplang is doing wrong.

-- 
Peter Eisentraut   peter_e@gmx.net



Re: droplang doesn't completely work?

From
Laurette Cisneros
Date:
On Sat, 14 Sep 2002, Peter Eisentraut wrote:

> Laurette Cisneros writes:
> 
> > 2) On a bkuphost system that has 7.2.2:
> >    createdb -T template0 x
> >    pg_restore -U xuser -h bkuphost -p 5432 -d x -Fc x.pgdmp
> >
> >    get error:
> >    pg_restore: [archiver (db)] could not execute query: ERROR:
> >    stat failed on file '/usr/local/pgsql-7.2/lib/plpgsql': No such file or
> >    directory
> 
> Well, is that file (+ .so) there?  What does this path refer to?  Is it
> the correct installation location?

Oops, sent the wrong error message, the message I get is:

pg_restore: [archiver (db)] could not execute query: ERROR:  Load of file
/usr/local/pgsql7.2.2/lib/plperl.so failed: libperl.so: cannot open shared
object file: No such file or directory

And, this is the point, libperl is not installed so I need to get rid of
references to the language.

> 
> > So, I go back to primary system and
> > droplang -d x plperl
> >
> > I do 1) and 2) again. Same ERROR.
> 
> Not surprising, since the error refers to plpgsql, not plperl.

Meant to send message for plperl...see above.

> 
> > So, I go back to primary system again, and for database x:
> > select proname, probin from pg_proc
> >
> > and see:
> > ...
> > plperl_call_handler      | $libdir/plperl
> > ...
> >
> > Shouldn't this be gone after I droplang?
> 
> Maybe you still have plperlu installed, in which case the language handler
> is kept.  Otherwise the answer is yes and you should try to see what
> droplang is doing wrong.

Yep, that was it!  Fixed now!

It's friday that's for sure.

Thanks,

-- 
Laurette Cisneros
The Database Group
(510) 420-3137
NextBus Information Systems, Inc.
www.nextbus.com
----------------------------------
A wiki we will go...