Re: First feature patch for plperl - draft [PATCH] - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: First feature patch for plperl - draft [PATCH]
Date
Msg-id 4B1A9268.2000805@dunslane.net
Whole thread Raw
In response to Re: First feature patch for plperl - draft [PATCH]  (Tim Bunce <Tim.Bunce@pobox.com>)
Responses Re: First feature patch for plperl - draft [PATCH]  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

Tim Bunce wrote:
>> That doesn't even begin to cover the problems with allowing any of
>> this to happen inside the postmaster.  Recall that the postmaster
>> does not have any database access.  Furthermore, it is a very long
>> established reliability principle around here that the postmaster
>> process should do as little as possible, because every thing that it
>> does creates another opportunity to have a nonrecoverable failure.
>> The postmaster can recover if a child crashes, but the other way
>> round, not so much.
>>     
>
> I hope the combination of disabling the SPI functions during
> initialization, and documenting the risks of combining on_perl_init and
> shared_preload_libraries, is sufficient.
>
>
>   

We already do a lot during library load - plperl's _PG_init() calls 
plperl_init_interp() which sets up an interpreter, runs the boot code, 
loads the Dynaloader and bootstraps the SPI module.

Pre-loading perl libraries in forking servers has well known benefits, 
as Robert Haas noted.

We're not talking about touching the database at all.

If we turn Tim's proposal down, I suspect someone will create a fork of 
plperl that allows it anyway - it's not like it needs anything changed 
elsewhere in the backend - it would be a drop-in replacement, pretty much.

Here's a concrete example of something I was working on just yesterday, 
where it would be useful. One of my clients has a Postgres based 
application that needs to talk to a number of foreign databases, mostly 
SQLServer. In some cases it pulls data from them, in this new case we 
are pushing lots of data at arbitrary times into SQLServer, using 
plperlu with DBI/DBD::Sybase. We would probably get a significant 
performance gain if we could have DBI and DBD::Sybase preloaded. The 
application does use connection pooling, but every so often a function 
call will take significantly longer because it occurs in a new backend 
that is having to reload the libraries.

I think if we do this the on_perl_init setting should probably be 
PGC_POSTMASTER, which would remove any issue about it changing 
underneath us.

cheers

andrew






pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: First feature patch for plperl - draft [PATCH]
Next
From: Tom Lane
Date:
Subject: Re: First feature patch for plperl - draft [PATCH]