2012/9/11 Alvaro Herrera <alvhe...@2ndquadrant.com>: > Excerpts from Kohei KaiGai's message of mar sep 11 12:46:34 -0300 2012: >> 2012/9/11 Alvaro Herrera <alvhe...@2ndquadrant.com>: >> > Excerpts from Boszormenyi Zoltan's message of vie jun 29 09:11:23 -0400 >> > 2012: >> > >> >> We have some use cases for this patch, when can you post >> >> a new version? I would test and review it. >> > >> > What use cases do you have in mind? >> > >> I'm motivated with this feature to implement background calculation server >> to handle accesses to GPU device; to avoid limitation of number of processes >> that can use GPU device simultaneously. > > Hmm, okay, so basically a worker would need a couple of LWLocks, a > shared memory area, and not much else? Not a database connection. > Right. It needs shared memory area to communicate with each backend and locking mechanism, but my case does not take database accesses right now.
>> Probably, other folks have their use cases. >> For example, Zoltan introduced his use case in the upthread as follows: >> > - an SQL-driven scheduler, similar to pgAgent, it's generic enough, >> > we might port it to this scheme and publish it > > Hm, this would benefit from a direct backend connection to get the > schedule data (SPI interface I guess). > I also think SPI interface will be first candidate for the daemons that needs database access. Probably, lower layer interfaces (such as heap_open and heap_beginscan) are also available if SPI interface can be used. 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
