plperl loading files - Mailing list pgsql-hackers

From Jeff Janes
Subject plperl loading files
Date
Msg-id CAMkU=1yEQozdtWvZgRrdJEsyY__enuFsGTcmFmePiP=JciSJJg@mail.gmail.com
Whole thread Raw
Responses Re: plperl loading files  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
After putting "plperl" into shared_preload_libraries so that things
get loaded upon server start, I was surprised to see that each backend
was still accessing a handful of perl files the first time it used a
plperl function.

I see that the cause is src/pl/plperl/plc_trusted.pl, which loads some
modules only when running plperl (not plperlu), and so it happens in
the backend rather than the postmaster.

Is there some pressing need for these module not to be loaded for use
with plperlu? I think the rationale is that plperlu can load them for
itself if it wants them, so they don't need to be loaded
automatically.  But I don't see why they need to not be loaded
automatically.  If that was changed then the loading could be moved to
the server start rather than each backend's first use of plperl(u).

If you really want to suppress this per-backend activity, you can
pre-emptively load the modules yourself with something like:

plperl.on_init ='require Carp; require Carp::Heavy; require feature;'

But, I don't see why that should be necessary.  I'd like to just put
plperl into shared_preload_libraries and be done with it.

Am I missing something here?

Cheers,

Jeff



pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: DO with a large amount of statements get stuck with high memory consumption
Next
From: Noah Misch
Date:
Subject: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <