On Mon, Nov 15, 2010 at 12:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Looking through the code, it appears to me that we'd need to do the
>> following (not necessarily in this order):
>
> Don't forget
>
> 9. Unload loadable modules that do not exist according to the new
> database's catalogs; eg we don't want postgis trying to run when
> its supporting tables don't exist in the selected database.
I might be missing something here, but I wasn't aware that the
catalogs had any say in what loadable modules exist. Obviously their
contents will determine whether such loadable modules ever get invoked
as a result of actions at the SQL level, but if they don't it may not
matter much that they're loaded but idle.
> 10. Somehow persuade remaining loadable modules to discard whatever
> state they have that might be database-local.
Ouch.
> We don't have workable APIs for either of those operations ATM.
Somewhat independently of this problem, it would be nice to be able to
unload a loadable module, and I think that we currently don't support
that at all. One thing (the only thing?) that makes that a
show-stopper is that the way we manage hook function chaining makes it
impossible for a module to reliably unload itself. If you load both
auto_explain and pg_stat_statements, for example, you end up with a
tangle of pointers that can't be easily unwound. I don't have a real
clear idea how to fix it, but the status quo certainly doesn't seem
optimal.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company