Re: Review: Extra Daemons / bgworker
Kohei KaiGai <kaigai@kaigai.gr.jp>
From: Kohei KaiGai <kaigai@kaigai.gr.jp>
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>
Cc: Andres Freund <andres@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Markus Wanner <markus@bluegap.ch>, PostgreSQL-development Hackers <pgsql-hackers@postgresql.org>
Date: 2012-11-30T13:55:33Z
Lists: pgsql-hackers
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>