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

Attachment: preload-spi.diff
Description: Binary data




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.
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to