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

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@momjian.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.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +