On Mon, Feb 18, 2013 at 10:46:39PM +0530, Atri Sharma wrote: > > > Sent from my iPad > > On 18-Feb-2013, at 22:38, Bruce Momjian <bruce@xxxxxxxxxx> wrote: > > > On Mon, Feb 18, 2013 at 10:33:26PM +0530, Atri Sharma wrote: > >>>> While your threads are executing, your query can't be cancelled -- > >>>> only a hard kill will take the database down. If you're ok with that > >>>> risk, then go for it. If you're not, then I'd thinking about > >>>> sendinging the bytea through a protocol to a threaded processing > >>>> server running outside of the database. More work and slower > >>>> (protocol overhead), but much more robust. > >>> > >>> You can see the approach of not calling any PG-specific routines from > >>> theads here: > >>> > >>> http://wiki.postgresql.org/wiki/Parallel_Query_Execution#Approaches > >> > >> > >> Is there any way to locally synchronise the threads in my code,and > >> send the requests to the PostgreSQL backend one at a time? Like a waiting > >> queue in my code? > > > > Is this from the client code? That is easy from libpq using > > asynchronous queries. > > > > > > Actually, I haven't yet faced any such scenario.I was just thinking of all the possibilities that can happen in this case.Hehehe > > If we want to do this from a function in PostgreSQL itself, would a local synchronisation mechanism work? So your server-side function wants to start a new backend --- yeah, that works. /contrib/dblink does exactly that. Calling it from threads should have the same limitations you would normally have from libpq. -- Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
