Hi,
Le 31 mai 09 à 18:21, Tom Lane a écrit :
> The reason this doesn't work is that SPI can only be invoked inside a
> transaction, and you're not inside one when a library is being
> preloaded.
Please find attached a little little patch which run
process_local_preload_libraries from within a transaction.
The following patch to preprepare makes it working fine when the GUC
preprepare.at_init is on and the module is being loaded from
local_preload_librairies:
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/preprepare/preprepare/pre_prepare.c.diff?r1=1.1&r2=1.2
> You could maybe make this work by executing your own transaction
> to do it
I took the option to have PostgreSQL provide the same context in
preloading that when loading later, in that in both case _PG_init()
runs inside an already existing transaction. I don't see a current way
for _PG_init() to distinguish between being called at backend fork()
time or from a user transaction, so figured it was better this way.
> but I really have to wonder if it's a good idea. One
> point to think about is that elog(ERROR) still means elog(FATAL)
> at this point, so any brokenness in the queries you're trying to
> prepare will result in locking all users out of the database.
Well loading custom code at init time is a foot-gun reserved to
superusers with access to the local file system (where to put the
custom .so) and allowed to signal postmaster. You're right that a
failure in the module init routine will prevent anyone from connecting
to the server, but the cure is to clean local_preload_librairies then
restart.
Or with the preprepare example, to set preprepare.at_init to off then
reload.
Regards,
--
dim
PS: sorry I don't have the toolsuite to provide a context diff
tonight, but given the size of the patch I figured I'd send it anyway.
Will cook a context diff tomorrow if needed, it's running late here.
Oh, we're already tomorrow, even.
