2012/11/30 Dimitri Fontaine <dimi...@2ndquadrant.fr>: > Kohei KaiGai <kai...@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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers