"Markus Schiltknecht" <[EMAIL PROTECTED]> wrote > Hi Qingqing, > > > > > As Tom pointed out, without big change, a backend on database "D1" can't > > connect to "D2". This is because to connect to a database, we need to > > initialize a lot of variables. So when you reconnect to another one on the > > fly, you have to change these variables one by one. > > Sure, the question is: what is needed to retarget a backend? > Check the code InitPostgres(). These global varaibles are scattered in many places, so I am not sure if it is easy to write clean code to clear up these variables. But if you can come up with a patch to do reconnect without disconnect, that will be cool.
> IMHO, in all of the three examples mentioned up-thread, it would be > better to retarget an existing backend, instead of forking a new one, > because that would perform better and/or save some resources. > That's for sure. > Please do also consider, that for parallel query execution as well as > for replaying remote transactions access rights checking and any client > connection setup could be omitted. Such special processing backeds could > easily be run with superuser privileges and without a client connection. > This is a problem for parallel query execution. I suspect we can't run with superuser privileges for now and for future. For now, I am not clear if there is any ACL check at query execution stage -- seems should not be, at least for DML. For future, I am pretty clear that this is not the way -- the mere possibility of future support of audit or MAC will bring in mind the reason. Regards, Qingqing ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly