> I can see a couple possible downsides: (a) the library might have some

> weird behavior across fork boundaries; (b) the additional memory space
> that has to be duplicated into child processes will cost something per
> child launch, even if the child never uses it.  But these are only
> arguments that it might not *always* be a prudent thing to do, not that
> we shouldn't give the DBA the tool to do it if he wants.  So fire away.

Here is a patch for the above, including a documentation update. It
creates a new GUC variable "preload_libraries", that accepts a list in
the form:

   preload_libraries = '$libdir/mylib1:initfunc,$libdir/mylib2'

If ":initfunc" is omitted or not found, no initialization function is
executed, but the library is still preloaded. If "$libdir/mylib" isn't
found, the postmaster refuses to start.

In my testing with PL/R, it reduces the first call to a PL/R function
(after connecting) from almost 2 seconds, down to about 8 ms.

Joe Conway

src/backend/postmaster/postmaster.c

@@ -37,7 +37,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v 1.307 2003/02/23 04:48:19 tgl Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v 1.308 2003/03/20 04:51:44 momjian Exp $
  *
  * NOTES
  *
@@ -205,6 +205,8 @@ bool		LogSourcePort;
 bool		Log_connections = false;
 bool		Db_user_namespace = false;
 
+/* list of library:init-function to be preloaded */
+char       *preload_libraries_string = NULL;
 
 /* Startup/shutdown state */
 static pid_t StartupPID = 0,
@@ -645,6 +647,13 @@ PostmasterMain(int argc, char *argv[])
 		secure_initialize();
 #endif
 
+	/*
+	 * process any libraries that should be preloaded and
+	 * optionally pre-initialized
+	 */
+	if (preload_libraries_string)
+		process_preload_libraries(preload_libraries_string);
+
 	/*
 	 * Fork away from controlling terminal, if -S specified.
 	 *