Re: forking child processes in src/backend/main/main.c - Mailing list pgsql-hackers

From Sailesh Krishnamurthy
Subject Re: forking child processes in src/backend/main/main.c
Date
Msg-id bxyznmgmhlo.fsf@datafix.CS.Berkeley.EDU
Whole thread Raw
In response to forking child processes in src/backend/main/main.c  ("S -" <nat_lazy@hotmail.com>)
List pgsql-hackers
>>>>> "S" == nat lazy <S> writes:
   S> Would anyone kindly suggest where would be the best place for   S> us to call fork() in this case?
   S> Would this src/backend/main/main.c be a good place to put the   S> fork() and server code?

In the TelegraphCQ project we have started with the postgres code base
and done something like what you are trying. More specifically, long
running continuous queries are run in a separate process (as is the
code that is responsible for streaming in data from external sources). 

The way we do it is to pass an extra argument to BackendStartup()
(which is called from serverloop() called from PostmasterMain()) - the
extra argument suggests whether or not the backend being started up is
a regular postgres process (that we call the TelegraphCQ Front-End) or
if its the query-processing backend (the TCQ BE) or the TCQ Wrapper
ClearingHouse. We make our separate calls to BackendStartup() right
before the serverloop in PostmasterMain() .. within BackendStartup we
run the appropriate code based on the extra argument passed.

You can look at a very-very alpha version of our code in
http://telegraph.cs.berkeley.edu/telegraphcq

TCQ 0.1 is based on pgsql-7.2.1 - however most of what I've said
should work on the new code base (we're currently merging upto 7.3.2). 

-- 
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh



pgsql-hackers by date:

Previous
From: "S -"
Date:
Subject: src/backend/storage/lmgr/lock.c ----> LockAcquire()
Next
From: Kevin Lo
Date:
Subject: Postgresql Filesystem