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=
