Removal of exec() patch applied
От | Bruce Momjian |
---|---|
Тема | Removal of exec() patch applied |
Дата | |
Msg-id | 199805291715.NAA28318@candle.pha.pa.us обсуждение исходный текст |
Список | 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@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)
В списке pgsql-hackers по дате отправления: