Re: changing MyDatabaseId - Mailing list pgsql-hackers

From Tom Lane
Subject Re: changing MyDatabaseId
Date
Msg-id 22541.1289799700@sss.pgh.pa.us
Whole thread Raw
In response to changing MyDatabaseId  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: changing MyDatabaseId
Re: changing MyDatabaseId
List pgsql-hackers
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.
10. Somehow persuade remaining loadable modules to discard whatever
state they have that might be database-local.

We don't have workable APIs for either of those operations ATM.

I believe also that there are probably race conditions in several of
the steps you listed; in particular there is certainly a risk involved
in changing the database-we-advertise-being-connected-to versus a
concurrent DROP DATABASE.  Maybe that's easily soluble, but I'm not sure
about it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: MULTISET and additional functions for ARRAY
Next
From: Heikki Linnakangas
Date:
Subject: Latches with weak memory ordering (Re: max_wal_senders must die)