Re: What happens if I create new threads from within a postgresql function?

Sent from my iPad

On 18-Feb-2013, at 22:58, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> 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(at)momjian(dot)us> 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.
>
>

Got that,thanks a ton!

I will see the dblink code.

BTW, is there no way to introduce a general synchronisation mechanism for server side code? A kind of construct which would be the standard way to manage synchronisation ? I was thinking of something on the lines of a monitor.

Atri