Re: What happens if I create new threads from within a postgresql function?
От | Atri Sharma |
---|---|
Тема | Re: What happens if I create new threads from within a postgresql function? |
Дата | |
Msg-id | C6194EB5-E1F1-4959-AF7B-EFD973CD87D8@gmail.com обсуждение исходный текст |
Ответ на | Re: What happens if I create new threads from within a postgresql function? (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: What happens if I create new threads from within a
postgresql function?
|
Список | pgsql-general |
Sent from my iPad On 18-Feb-2013, at 22:58, Bruce Momjian <bruce@momjian.us> wrote: > On Mon, Feb 18, 2013 at 10:46:39PM +0530, Atri Sharma wrote: >>=20 >>=20 >> Sent from my iPad >>=20 >> On 18-Feb-2013, at 22:38, Bruce Momjian <bruce@momjian.us> wrote: >>=20 >>> 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. >>>>>=20 >>>>> You can see the approach of not calling any PG-specific routines from >>>>> theads here: >>>>>=20 >>>>> http://wiki.postgresql.org/wiki/Parallel_Query_Execution#Approaches >>>>=20 >>>>=20 >>>> 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 waiti= ng >>>> queue in my code? >>>=20 >>> Is this from the client code? That is easy from libpq using >>> asynchronous queries. >>>=20 >>>=20 >>=20 >> Actually, I haven't yet faced any such scenario.I was just thinking of al= l the possibilities that can happen in this case.Hehehe >>=20 >> If we want to do this from a function in PostgreSQL itself, would a local= synchronisation mechanism work? >=20 > 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. >=20 >=20 Got that,thanks a ton! I will see the dblink code. BTW, is there no way to introduce a general synchronisation mechanism for se= rver side code? A kind of construct which would be the standard way to manag= e synchronisation ? I was thinking of something on the lines of a monitor. Atri=
В списке pgsql-general по дате отправления: