Re: [HACKERS] pg_regress in C

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Tue, Jul 18, 2006 at 10:46:04PM -0400, Tom Lane wrote:
>> ... One reason I didn't try to do this is I'm a bit hesitant to
>> write a signal handler that does anything as interesting as a system()
>> call, which would seem to be necessary to duplicate what the shell
>> script did. Comments?

> It might not actually be unsafe, given system() actually blocks on
> waitpid() which is specifically listed as a "safe" function. I'm a bit
> confused though, because system() generally sets the parent to ignore
> SIGINT which running the child process. That means the postmaster is
> being killed but pg_regress is not? If this is the case, then you won't
> be able to catch SIGINT anyway.

The cases of interest are where the (new) code goes through
spawn_process, which does a fork() and then calls system() in the
child. So the intermediate child is probably SIGINT-blocked, but
pg_regress itself isn't.

I was planning to rewrite spawn_process anyway, because I noticed that
as it's currently set up, we are actually creating four(!) processes per
parallel test: the pg_regress child, the shell invoked by system, the
psql invoked by the shell, and the connected backend. That's even worse
than the shell script, which (at least on my system) used three processes.
I believe we can get down to two (psql and backend) if spawn_process
exec's the shell instead of using system, and also puts "exec" in front
of the command string passed to the shell. So in that scenario there'd
not be any signal-blocking going on anyway.

That still leaves us with the question of whether pg_regress needs to do
anything special when signaled, though.

regards, tom lane