From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Feedback on writing extensible modules |
Date: | 2009-05-31 19:58:28 |
Message-ID: | 45633DE2-1E06-454C-AAE7-75325E852154@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
First, thank you to have taken the time to see about the case.
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.
Makes sense. Still crashing with basic naive testing, will report back
when I have more time to work on it.
> You could maybe make this work by executing your own transaction
> to do it, 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.
Yeah that's a pretty good foot gun, yet another one. But
preprepare.at_init is optional and defaults to off. If you broke it
all, you can turn it off again and reload.
As for the FATAL, I guess that having preprepare crashing backend
creations rather than having your EXECUTE fail and ROLLBACK your
transactions is not so much a difference when you need preprepare in
the first place...
I'll add a note in the documentation to always manually call SELECT
prepare_all() at each prepare statements list modification before to
turn at_init on, as soon as at_init is possible.
Regards,
--
dim
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-05-31 20:07:40 | Re: Dtrace probes documentation |
Previous Message | Andrew Dunstan | 2009-05-31 19:53:13 | Re: check for missing tablespaces? |