Re: Review: Extra Daemons / bgworker

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Markus Wanner <markus(at)bluegap(dot)ch>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: Extra Daemons / bgworker
Date: 2012-11-30 13:42:55
Message-ID: m2wqx39pgg.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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?

> 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?

> 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.

--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-11-30 13:44:43 Re: Review: Extra Daemons / bgworker
Previous Message Pavan Deolasee 2012-11-30 13:32:14 Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?