Re: Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)
От | Tom Lane |
---|---|
Тема | Re: Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85) |
Дата | |
Msg-id | 12922.1068315231@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85) (Bob Ippolito <bob@redivi.com>) |
Ответы |
Re: Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)
|
Список | pgsql-hackers |
Bob Ippolito <bob@redivi.com> writes: > On Nov 8, 2003, at 12:31 AM, Tom Lane wrote: >> I have just in the past couple hours realized that ps_status.c is >> seriously broken on OS X 10.3. > Er... I meant memcmp.. Have you tried removing the system.c hack? > That's what fixed it for me. AFAICT system.c hasn't got anything to do with the problem that I'm seeing; it's purely a matter of ps_status.c clobbering argv[] contents that the dynamic loader depends on for some weird reason. It looks like Apple's implementation stores a copy of the original argc count, and there is a bit of code in the loader that for some reason is examining each argv string from 0..original_argc-1. Who knows why :-( ... but where we set save_argv[1] to NULL, we create a null pointer crash in the loader. Take that out, no crash. You would not see this crash if you started the postmaster with no command-line arguments, btw. I'm planning to change ps_status so that instead of zeroing save_argv[1], it makes all the original argv strings be pointers to "" except for argv[0]. As for getting rid of system.c, I am not eager to do that since it would certainly break compatibility with OS X 10.1. We could conditionally compile it out perhaps. Do you know what #define symbol we could test for to determine which OS X version we are on? regards, tom lane
В списке pgsql-hackers по дате отправления: