Re: C vs plpgsql and child processes - Mailing list pgsql-general

From Jason Godden
Subject Re: C vs plpgsql and child processes
Date
Msg-id 200308190019.38463.jasongodden@optushome.com.au
Whole thread Raw
In response to Re: C vs plpgsql and child processes  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-general
Hi Jan/Sean

To the list I bow and apologise for wasting your time!  I did not
appropriately test the function (as is my want!) and passed command line
arguments in the executable image path in the execl function.  Now I edit my
table containing the configuration vars for the trackformat to decoder info
and everything purrs.. sigh.  Writing help requests to the list when you've
only exhausted half the possibilities are a bit silly.

Thanks for your time,

Jason

On Mon, 18 Aug 2003 11:41 pm, Jan Wieck wrote:
> Jason Godden wrote:
> > Hi Sean,
> >
> > Yeah - It is declared VOLATILE.  I think there must be something specific
> > with the way PL/PGSQL handles child processes of a called function.  The
> > child process actually spawns mpg123 or ogg123 so it has to live beyond
> > the life of the parent.  Not sure.  What I might do is rewrite the entire
> > procedure from woe to go in using SPI and see how that goes.  Failing
> > that I guess I could always peek at the source! : )
>
> PL/pgSQL does not pay any attention or could affect child processes of a
> backend to my knowledge. Are you sure that the PL/pgSQL function really
> calls your C function forking off the child? The best way to check would
> be to have some NOTICE coming out of your C function before it actually
> does create the child.
>
>
> Jan
>
> > Thanks,
> >
> > Jason
> >
> > On Mon, 18 Aug 2003 04:48 am, Sean Chittenden wrote:
> >> > Problem is that when I call these particular functions from within
> >> > plpgsql rather than through a single sql command the child never
> >> > actually starts (or starts and then exits immediately).
> >>
> >> Are you sure?  I can't think of much that'd prevent a C function from
> >> executing other than how you've declared the function (ie, is PgSQL
> >> caching the results of the function?).  Make sure you've declared it
> >> as VOLATILE (or don't declare it anything and it'll default to
> >> VOLATILE).
> >>
> >> http://developer.postgresql.org/docs/postgres/sql-createfunction.html
> >>
> >> -sc
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 9: the planner will ignore your desire to choose an index scan if
> > your joining column's datatypes do not match


pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Cache lookup failed?
Next
From: "Pablo Dall'Oglio"
Date:
Subject: Re: XML?