Re: Review: Extra Daemons / bgworker - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Review: Extra Daemons / bgworker
Date
Msg-id m2wqx39pgg.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Review: Extra Daemons / bgworker  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: Review: Extra Daemons / bgworker  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
List pgsql-hackers
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?

> 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



pgsql-hackers by date:

Previous
From: Pavan Deolasee
Date:
Subject: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?
Next
From: Alvaro Herrera
Date:
Subject: Re: Review: Extra Daemons / bgworker