Re: Support Parallel Query Execution in Executor

"Markus Schiltknecht" <markus(at)bluegap(dot)ch> 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