Removal of exec() patch applied

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: hackers(at)postgreSQL(dot)org (PostgreSQL-development)
Subject: Removal of exec() patch applied
Date: 1998-05-29 17:15:29
Message-ID: 199805291715.NAA28318@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I have completed removal of exec(), so now the postmaster just forks a
child, and the child runs sharing the same address space, rather than
forking the same binary.

In doing this, I had to consider the changes that exec performs in the
old fork/exec. There are a few main issues. First, the signal handlers
and sigmask are inherited from the parent, and have to be reset.
Fortunately, they are blocked at the fork() point in the code, so it is
easy to change them before unblocking. The second issue is that any
initialized variables that were modified by the postmaster AND should be
the old values in the child had to be reset. There were only a few of
these, but they were tricky to find. Fortunately, the child does not do
much. If I missed any other interactions of exec(), please let me know.

Third, I found that the child could not dynamically load files because
it had changed directories to the database dir, and the BSDI load was
using argv[0], which was relative to the startup directory, not the
current one. A good fix was to get argv[0] in the child to be absolute
path 'postgres' binary, which is how the old exec() worked anyway. That
worked great, and actually caused 'ps' to show 'postgres' for the child
rather than 'postmaster'. If this is the same for others, I recommend
we keep both binaries, so we can easily invoke either, and show them in
'ps' with proper names.

The regression tests pass, so I am applying the patch to the main source
tree. People, let me know if you see problems on your platforms. I
have posted the patch to the patches list for review.

I think this opens up a lot of things we can now do once in the
postmaster, rather than doing them in every backend.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)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)

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-05-29 17:28:23 Re: [HACKERS] Sequential scan speed, mmap, disk i/o]
Previous Message Tatsuo Ishii 1998-05-29 15:07:49 Re: [HACKERS] comm patch & ssl patch