{ texts for nothing }

Here in British Columbia, public libraries get a big chunk of their funding from the provincial government in the form of annual operating grants.* This year’s grants have yet to be distributed, even though we’re already four months into the new fiscal year. If that money isn’t received, we could see substantial cuts to programs and services — stuff like access to online resources, sharing of materials between libraries (giving patrons access to stuff that they just can’t get at their local library), and literacy programs for kids like the BC Summer Reading Club and Books for Babies. The chief librarian at Vancouver Public Library is already talking about reduced hours of operation and even branch closures. And the head of the BC Library Trustees Association has pointed out that “a cut to this year’s grant would guarantee there will be cuts in the future.”

During the last election, Premier Gordon Campbell talked about making BC “the best educated, most literate jurisdiction on the continent.” Now his government is planning to cut funding for public libraries, which play a fundamental role in education and literacy. Even worse, this is happening at a time when libraries across the province have seen big surges in use because of the ongoing economic crisis. People are using library resources (books, the reference desk, free public Internet access) to look for work, to find other ways to make ends meet, or even just to cope with uncertainty and stress. Not only is the provincial government threatening to undermine an essential service, they’re doing it at precisely the moment when that service is needed most.

Heckuva job, Gordo.

Imagine being Buzz Aldrin. You’re the second human being to set foot on the Moon, a central figure in one of the most amazing experiences in human history. Everything afterward savors of anti-climax. But on a clear night you can still step outside, look up at the Moon, and say to yourself, “Yeah, I’ve been there.”

(Then, because you’re a Real American Hero, you go and punch a moon-landing denier in the face.)

Today is the 40th anniversary of the first Moon landing. If that sort of thing interests you, I recommend taking a look at a most excellent documentary called For All Mankind. (By a strange coincidence, I happened to watch the film last night, not realizing how appropriate my timing was.) Rather than taking the usual chronological approach, the movie stitches together archival footage from a bunch of different Apollo missions to tell the story of the six Moon landings as if they were all a single flight. The various astronauts who provide voice-over narration aren’t even individually identified. There’s relatively little technical or historical detail; instead, the focus is on what it was like for human beings to take a trip to the Moon.

As a result, you get quotes like this one from Michael Collins, the third guy on the Apollo 11 mission, talking about what went through his mind as he watched the other two astronauts head down to the lunar surface without him:

Neil Armstrong and Buzz Aldrin were right in front of me in the lunar module, and then simultaneously the Earth popped up right behind them, so that I could say to myself, “Well, look, that’s all there are. There they are. Three billion people there, and two people there, and that’s all there are.”

Not bad for a bunch of apes.

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.)