Force plperl and plperlu to run in separate interpreters. Create an error

on an attempt to create the second interpreter if this is not supported by
the perl installation. Per recent -hackers discussion.

diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
index b9668103ecdfdc67a54ed95d5c7975292a2035b6..a94163e7be693064e59603e05bae100ea777cc14 100644 (file)
--- a/doc/src/sgml/plperl.sgml
+++ b/doc/src/sgml/plperl.sgml
@@ -1,4 +1,4 @@
-
+
 
  
   PL/Perl - Perl Procedural Language
@@ -646,6 +646,25 @@ $$ LANGUAGE plperl;
    If the above function was created by a superuser using the language
    plperlu, execution would succeed.
   
+
+  
+    
+     For security reasons, to stop a leak of privileged operations from
+      PL/PerlU to PL/Perl, these two languages
+     have to run in separate instances of the Perl interpreter. If your
+     Perl installation has been appropriately compiled, this is not a problem.
+     However, not all installations are compiled with the requisite flags.
+     If PostgreSQL detects that this is the case then it will
+     not start a second interpreter, but instead create an error. In
+     consequence, in such an installation, you cannot use both 
+     PL/PerlU and PL/Perl in the same backend
+     process. The remedy for this is to obtain a Perl installation created
+     with the appropriate flags, namely either usemultiplicity or
+     both usethreads and useithreads. 
+     For more details,see the perlembed manual page.
+    
+  
+  
  
 
  

diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml
index 58b4eaf50b0463d9baa66aaf50820b7b1b32e565..78a72cea00821c832e9125500f1d51b938c1deb9 100644 (file)
--- a/doc/src/sgml/release.sgml
+++ b/doc/src/sgml/release.sgml
@@ -1,4 +1,4 @@
-
+