By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,903 Members | 1,086 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,903 IT Pros & Developers. It's quick & easy.

restore error - language "plperlu" is not trusted

P: n/a
Greetings,

I just had to dump and restore one of my DBs (7.4RC2), and I got an
interesting message.

I first did:

pg_dump dbname > db_restore.sql

Then at console did the following:

\i db_restpre.sql

which performed everything as expected with the following ERROR
message:

ERROR: language "plperlu" is not trusted

and it gave a line number, which contained the following:

GRANT ALL ON LANGUAGE plperlu TO postgres WITH GRANT OPTION;

Now, my plperlu functions seem to behaving as expected (they read from
and write to /tmp). Should I be worried?

Cheers,

Chris

--
Christopher Murtagh
Enterprise Systems Administrator
ISR / Web Communications Group
McGill University
Montreal, Quebec
Canada

Tel.: (514) 398-3122
Fax: (514) 398-2017

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 12 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
On 17 Dec 2003, Christopher Murtagh wrote:
Greetings,

I just had to dump and restore one of my DBs (7.4RC2), and I got an
interesting message.

I first did:

pg_dump dbname > db_restore.sql

Then at console did the following:

\i db_restpre.sql

which performed everything as expected with the following ERROR
message:

ERROR: language "plperlu" is not trusted

and it gave a line number, which contained the following:

GRANT ALL ON LANGUAGE plperlu TO postgres WITH GRANT OPTION;

Now, my plperlu functions seem to behaving as expected (they read from
and write to /tmp). Should I be worried?


Did you install plperlu ahead of time as the super user, then run your
restore as the regular database owner?
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #2

P: n/a
On Wed, 2003-12-17 at 10:55, scott.marlowe wrote:
which performed everything as expected with the following ERROR
message:

ERROR: language "plperlu" is not trusted

and it gave a line number, which contained the following:

GRANT ALL ON LANGUAGE plperlu TO postgres WITH GRANT OPTION;

Now, my plperlu functions seem to behaving as expected (they read from
and write to /tmp). Should I be worried?


Did you install plperlu ahead of time as the super user, then run your
restore as the regular database owner?


No, I hadn't, I guess I had assumed that the restore would do that.
More interestingly, I did the restore on a different
machine/architecture (PPC instead of Intel) running 7.4 final release
(instead of RC2) and I didn't get the error message. However all of my
plperlu triggers seem to behaving normally. When I tried to install
plperlu afterwards I got this:

createlang plperlu a
createlang: language "plperlu" is already installed in database "a"

Hrm... Ah well. I'll know for next time to install the language first,
I just hope it won't bit me in the ass before then. :-)

Cheers,

Chris

--
Christopher Murtagh
Enterprise Systems Administrator
ISR / Web Communications Group
McGill University
Montreal, Quebec
Canada

Tel.: (514) 398-3122
Fax: (514) 398-2017

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #3

P: n/a
Christopher Murtagh <ch*****************@mcgill.ca> writes:
[ pg_dump script failed with ]
ERROR: language "plperlu" is not trusted
and it gave a line number, which contained the following:
GRANT ALL ON LANGUAGE plperlu TO postgres WITH GRANT OPTION;


Hm. The backend flat-out rejects all attempts at GRANT on untrusted
languages, even if you are superuser and the grantee is too. I'm not
totally sure about the rationale for that (Peter?) but in any case
pg_dump has evidently not gotten the word. If we think the backend's
behavior is right then we'd better change pg_dump to suppress trying
to GRANT permissions on untrusted languages.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #4

P: n/a
Tom Lane wrote:
Hm. The backend flat-out rejects all attempts at GRANT on untrusted
languages, even if you are superuser and the grantee is too. I'm not
totally sure about the rationale for that (Peter?)
Why would you need it? It's only going to create fuss about useless
functionality.
but in any case
pg_dump has evidently not gotten the word. If we think the backend's
behavior is right then we'd better change pg_dump to suppress trying
to GRANT permissions on untrusted languages.


There should not be any permissions, so there should be nothing to dump.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05 #5

P: n/a
Peter Eisentraut <pe*****@gmx.net> writes:
Tom Lane wrote:
pg_dump has evidently not gotten the word. If we think the backend's
behavior is right then we'd better change pg_dump to suppress trying
to GRANT permissions on untrusted languages.
There should not be any permissions, so there should be nothing to dump.


Uh, no, because you can say something like
revoke all on language plperlu from public;
and end up with non-null lanacl (because it instantiates the default
assumption that the owner has all privileges).

We could possibly hack the backend to avoid that, but I think pg_dump
will need the special-case test anyway since it has to be able to cope
with existing databases, wherein lanacl may be non-null.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #6

P: n/a
Tom Lane wrote:
Uh, no, because you can say something like
revoke all on language plperlu from public;
and end up with non-null lanacl (because it instantiates the default
assumption that the owner has all privileges).
OK, that needs to be disallowed.
We could possibly hack the backend to avoid that, but I think pg_dump
will need the special-case test anyway since it has to be able to
cope with existing databases, wherein lanacl may be non-null.


So far we know of 1 such database. I'd like to see some more before we
bother about it.
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #7

P: n/a
Peter Eisentraut <pe*****@gmx.net> writes:
Tom Lane wrote:
Uh, no, because you can say something like
revoke all on language plperlu from public;
and end up with non-null lanacl (because it instantiates the default
assumption that the owner has all privileges).
OK, that needs to be disallowed.
Fair enough. I thought it was a bit odd to disallow GRANT but allow
REVOKE anyway.
We could possibly hack the backend to avoid that, but I think pg_dump
will need the special-case test anyway since it has to be able to
cope with existing databases, wherein lanacl may be non-null.

So far we know of 1 such database. I'd like to see some more before we
bother about it.


It's a one-line addition --- just put the dumpACL call inside
"if (lanpltrusted)". I think it is a reasonable change. We'd have to
do something anyway, because the existing pg_dump code is certainly
broken for dumping untrusted languages from pre-7.3 databases (it
assumes a nonempty lanacl setting in that case).

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.