Re: First feature patch for plperl - draft [PATCH]

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