2012/11/30 Dimitri Fontaine <dimitri@2ndquadrant.fr>:
> Andres Freund <andres@2ndquadrant.com> writes:
>>> One of the uses for bgworkers that don't have shmem connection is to
>>> have them use libpq connections instead. I don't really see the point
>>> of forcing everyone to use backend connections when libpq connections
>>> are enough. In particular, they are easier to port from existing code;
>>> and they make it easier to share code with systems that still have to
>>> support older PG versions.
>
> Exactly, I think most bgworker would just use libpq if that's available,
> using a backend's infrastructure is not that good a fit here. I mean,
> connect from your worker to a database using libpq and call a backend's
> function (provided by the same extension I guess) in there.
>
> That's how I think pgqd would get integrated into the worker
> infrastructure, right?
>
One thing we have to pay attention is, the backend code cannot distinguish
connection from pgworker via libpq from other regular connections, from
perspective of access control.
Even if we implement major portion with C-function, do we have a reliable way
to prohibit C-function being invoked with user's query?
I also plan to use bgworker to load data chunk from shared_buffer to GPU
device in parallel, it shall be performed under the regular access control
stuff.
I think, using libpq is a good "option" for 95% of development, however, it
also should be possible to use SPI interface for corner case usage.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
