removing the exec() from doexec()

I'm planning on removing the exec from DoExec() and instead just
dispatch to the appropriate function.

I don't plan on any changes to the usage of "arguments" to this new
process, basically I'll just store them somewhere and then the forked
backend can process them.

Is there anything I should keep in mind? I'd like this to eventually
be integrated into the source tree -- any particular reason why we use
exec() when we're just re-invoking the same binary?

p.s. this is so my ssl patch doesn't have to negotiate twice -- very expensive

No reason for the exec(). I believe the only advantage is that it gives
us a separate process name in the 'ps' listing. I have looked into
simulating this.

This exec() takes 15% of our startup time. I have wanted it removed for
many releases now. The only problem is to rip out the code that
re-attached to shared memory and stuff like that, because you will no
longer loose the shared memory in the exec(). The IPC code is
complicated, so good luck. I or others can help if you get stuck.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

This exec() takes 15% of our startup time. I have wanted it removed for
many releases now. The only problem is to rip out the code that
re-attached to shared memory and stuff like that, because you will no
longer loose the shared memory in the exec(). The IPC code is
complicated, so good luck. I or others can help if you get stuck.

Another item is to no longer use SYSV shared memory but use
mmap(MAP_ANON) because this allows a much larger amount of shared memory
to be used.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

On Wed, 29 April 1998, at 21:53:36, Bruce Momjian wrote:

This exec() takes 15% of our startup time. I have wanted it removed for
many releases now. The only problem is to rip out the code that
re-attached to shared memory and stuff like that, because you will no
longer loose the shared memory in the exec(). The IPC code is
complicated, so good luck. I or others can help if you get stuck.

Another item is to no longer use SYSV shared memory but use
mmap(MAP_ANON) because this allows a much larger amount of shared memory
to be used.

What are the portability issues? I haven't written much portable
code, and certainly not with IPC.

On Wed, 29 April 1998, at 21:53:36, Bruce Momjian wrote:

This exec() takes 15% of our startup time. I have wanted it removed for
many releases now. The only problem is to rip out the code that
re-attached to shared memory and stuff like that, because you will no
longer loose the shared memory in the exec(). The IPC code is
complicated, so good luck. I or others can help if you get stuck.

Another item is to no longer use SYSV shared memory but use
mmap(MAP_ANON) because this allows a much larger amount of shared memory
to be used.

What are the portability issues? I haven't written much portable
code, and certainly not with IPC.

Not sure. mmap() is pretty portable. We will shake out any portability
issues as we go, or you can ask the list if everyone has such-and-such a
function.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

On Wed, 29 Apr 1998, Bruce Momjian wrote:

No reason for the exec(). I believe the only advantage is that it gives
us a separate process name in the 'ps' listing. I have looked into
simulating this.

Under FreeBSD, there is:

setproctitle(3) - set the process title for ps 1

This isn't available under Solaris though, last I checked...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

sure enough.. well, try this on your OS and you can find out if perl
knows how to change it. it doesn't work under solaris. the args to
ps might be different for your system.

perl -e '$0 = "it_works!";system "ps -p $$"'

However, the args to the processes are so different that it seems easy
to tell the difference.. if you're a human. computers might have
more trouble. I've been known to use "killall postgres" (yes, I know,
I'm bad!!)

I only do it so that I can restart the postmaster. Our webserver is
pretty much continually connected, and when it deadlocks, all the
clients queue up. It would be nice to have a set of commands to show
you all connections, the machine/remote port they're from (for
identd), the username/dbname they're connected as, when they
connected, idle time, etc. like "finger" for postgres.

I'm willing to work on it, if someone can point me in the right
direction. (First things first though)

On Wed, 29 April 1998, at 23:20:52, The Hermit Hacker wrote:

On Wed, 29 Apr 1998, Bruce Momjian wrote:

No reason for the exec(). I believe the only advantage is that it gives
us a separate process name in the 'ps' listing. I have looked into
simulating this.

Under FreeBSD, there is:

setproctitle(3) - set the process title for ps 1

This isn't available under Solaris though, last I checked...

Not even BSDI, which is BSD 4.4 like FreeBSD.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

sure enough.. well, try this on your OS and you can find out if perl
knows how to change it. it doesn't work under solaris. the args to
ps might be different for your system.

perl -e '$0 = "it_works!";system "ps -p $$"'

However, the args to the processes are so different that it seems easy
to tell the difference.. if you're a human. computers might have
more trouble. I've been known to use "killall postgres" (yes, I know,
I'm bad!!)

The args don't change on a fork() either. The only way is to look at
the parent of all the postgres children.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

On Wed, 29 Apr 1998, Bruce Momjian wrote:

No reason for the exec(). I believe the only advantage is that it gives
us a separate process name in the 'ps' listing. I have looked into
simulating this.

Under FreeBSD, there is:

setproctitle(3) - set the process title for ps 1

This isn't available under Solaris though, last I checked...

Not even BSDI, which is BSD 4.4 like FreeBSD.

ubik:~$ uname -a
Linux ubik 2.0.32 #1 Wed Nov 19 00:46:45 EST 1997 i586 unknown
ubik:~$ perl -e '$0 = "it_works!";system "ps p $$"'
PID TTY STAT TIME COMMAND
7629 p8 S 0:00 it_works!

-dg

-----Original Message-----
From: Bruce Momjian <maillist@candle.pha.pa.us>
To: maillist <maillist@candle.pha.pa.us>
Cc: brett@abraxas.scene.com <brett@abraxas.scene.com>; pgsql-hackers@hub.org
<pgsql-hackers@hub.org>
Date: donderdag 30 april 1998 10:12
Subject: Re: [HACKERS] removing the exec() from doexec()

This exec() takes 15% of our startup time. I have wanted it removed for
many releases now. The only problem is to rip out the code that
re-attached to shared memory and stuff like that, because you will no
longer loose the shared memory in the exec(). The IPC code is
complicated, so good luck. I or others can help if you get stuck.

I tried to replace the execs with forks once (an hour or two job).
Indeed I got some shared memory initialisations problems.

I got distracted before I finished it.

Success.

With regrads from Maurice.

On Wed, 29 Apr 1998, Bruce Momjian wrote:

No reason for the exec(). I believe the only advantage is that it gives
us a separate process name in the 'ps' listing. I have looked into
simulating this.

Under FreeBSD, there is:

setproctitle(3) - set the process title for ps 1

This isn't available under Solaris though, last I checked...

Not even BSDI, which is BSD 4.4 like FreeBSD.

ubik:~$ uname -a
Linux ubik 2.0.32 #1 Wed Nov 19 00:46:45 EST 1997 i586 unknown
ubik:~$ perl -e '$0 = "it_works!";system "ps p $$"'
PID TTY STAT TIME COMMAND
7629 p8 S 0:00 it_works!

Let me clarify. BSDI does not have setproctitle, but the perl test does
works, sort of:

$ perl -e '$0 = "it_works!";system "ps -p $$"'
PID TT STAT TIME COMMAND
13095 pc S+ 0:00.02 it_works! rks! ! (perl)

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

The Hermit Hacker <scrappy@hub.org> writes:

On Wed, 29 Apr 1998, Bruce Momjian wrote:

No reason for the exec(). I believe the only advantage is that it gives
us a separate process name in the 'ps' listing. I have looked into
simulating this.

Under FreeBSD, there is:
setproctitle(3) - set the process title for ps 1
This isn't available under Solaris though, last I checked...

Setting the process title from C is messy, but there is a readily
available reference. The Berkeley sendmail distribution includes code
to emulate setproctitle on practically every platform. See conf.h and
conf.c in any recent sendmail release. Warning: it's grotty enough to
make a strong man weep. Don't read near mealtime ;-)

regards, tom lane

Bruce Momjian <maillist@candle.pha.pa.us> writes:

This exec() takes 15% of our startup time. I have wanted it removed for
many releases now.

Don't forget that you will have to use a real fork() rather than
vfork(). Some of the apparent savings will not materialize.

I agree, though, that using exec() to reinvoke the same binary is
pretty silly, especially when you don't want exec's normal side-effects
of detaching shared mem etc. And being able to rip out the dependency
on whether vfork() exists would be nice.

regards, tom lane

Setting the process title from C is messy, but there is a readily
available reference. The Berkeley sendmail distribution includes code
to emulate setproctitle on practically every platform. See conf.h and
conf.c in any recent sendmail release. Warning: it's grotty enough to
make a strong man weep. Don't read near mealtime ;-)

Yep, I have seen it. Good advice. What does grotty mean?

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Bruce Momjian <maillist@candle.pha.pa.us> writes:

What does grotty mean?

Hmm, I thought for sure that would be in the Hackers' Dictionary,
but not so. Anyway, it means ugly, messy, contorted, bletcherous,
random.

After you read sendmail's setproctitle code, you'll understand ;-)

regards, tom lane