2012/11/30 Dimitri Fontaine <dimitri@2ndquadrant.fr>:
> Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
>> 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?
>
> Why would you want to do that? And maybe the way to enforce that would
> be by having your extension do its connecting using SPI to be able to
> place things in known pieces of memory for the function to check?
>
As long as SPI is an option of bgworker, I have nothing to argue here.
If the framework enforced extension performing as background worker using
libpq for database connection, a certain kind of works being tied with internal
stuff has to be implemented as C-functions. Thus, I worried about it.
>> 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.
>
> That sounds like a job where you need shared memory access but maybe not
> a database connection?
>
Both of them are needed in this case. This "io-worker" will perform according
to the request from regular backend process, and fetch tuples from the heap
to the DMA buffer being on shared memory.
>> 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.
>
> +1, totally agreed.
>
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
