Re: loading libraries on Postmaster startup - Mailing list pgsql-hackers

From Greg Stark
Subject Re: loading libraries on Postmaster startup
Date
Msg-id 87k7g4ls5o.fsf@stark.dyndns.tv
Whole thread Raw
In response to loading libraries on Postmaster startup  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
Joe Conway <mail@joeconway.com> writes:

> 2. It seems to me that other libraries such as those for PL/Tcl,
>      PL/Perl, etc may have the same issue. Is there any merit in
>      a GUC variable to allow libraries such as this to be loaded
>      and initialized at postmaster start? I'll generalize this and
>      send in a patch if there is interest.

A similar situation arises with mod_perl. Because perl is quite heavy-weight
and systems often need lots of packages with static data it's common to load a
startup.pl script that just loads lots of packages before the Apache server
forks. This reduces memory usage drastically.

The main gotcha is that you have to be careful about resources that you don't
want shared. The typical case is database handles which are sockets that
wouldn't be happy having two processes writing and reading on them.

At first blush it seemed unlikely you would have a database connection in an
embedded perl script. But then, hm, that would be a sly way of doing
interdatabase connections. In any case there are other situations where you
might want to have open file descriptors or sockets lying around.

So in short, not only is it useful, but it would be valuable to allow
mechanism to cause the language to load modules before forking. But there have
to be prominent caveats that no such shared packages should create resources
that can't be safely shared.

--
greg



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: loading libraries on Postmaster startup
Next
From: Tom Lane
Date:
Subject: Re: psql source suggestions