This post is about an obscure error I encountered while using the PostgreSQL database engine. Googling the error text did not lead directly to an explanation of the problem, so I’m posting what I discovered here. (If you don’t know what PostgreSQL is, this won’t mean anything to you. Sorry!)

Here’s the text of the error:

ERROR:  can not allocate second Perl interpreter on this platform

If you get this error message, you are probably trying to use Pl/Perl and Pl/PerlU at the same time, but your installation of Perl isn’t compiled in a way that permits that.

Let me explain. One of the nice things about Postgres is that you can create your own functions if there isn’t a built-in function that does what you want. Even better, since Postgres is capable of understanding Perl, you can write your own functions in Perl and run them directly in Postgres. In fact, Perl can be run within Postgres in two separate ways: as a “trusted” language with some of Perl’s features disabled for security reasons (Pl/Perl), or as an “untrusted” language with the full range of Perl functionality available (Pl/PerlU).

Now, you can set up a single database to be capable of using both Pl/Perl and Pl/PerlU, but Postgres runs the two languages separately, as distinct “instances” of Perl. Depending on how your local installation of Perl is configured, it might not be able to handle that. As the Postgres manual says:

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.

In other words, if you want to use both Pl/Perl and Pl/PerlU at the same time but you’re getting the “can not allocate second Perl interpreter” error, the correct solution is to recompile Perl. I didn’t want to do that, so I just switched to using one Perl-based procedural language at a time (either Pl/PerlU or Pl/Perl, but not both). Fortunately, in my particular situation, this wasn’t a problem.

(I ran into this obscure problem because my day job involves migrating libraries from their legacy computer systems onto Evergreen, an open source integrated library system that uses a Postgres database backend. Naturally, we have to do some manipulation of the data that we get from the libraries before we can insert it into our installation of Evergreen. Being able to use Perl directly in the database makes the data manipulation much easier.)