Re: [HACKERS] Platforms with v6.3 trouble
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] Platforms with v6.3 trouble |
Дата | |
Msg-id | 34F4569A.99827B07@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Platforms with v6.3 trouble (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Platforms with v6.3 trouble
|
Список | pgsql-hackers |
> > Since these macros were inlined only for performance reasons, would it > > be possible to revert to non-inline function calls for these platforms? > > It would seem that substituting a macro expansion for a compiled routine > > could be done with a compiler switch (e.g. USE_INLINING) so it could be > > turned on and off at will. > > > > For most of us, the performance gains are fantastic, but for those ports > > which broke performance has degraded to zero :( > > Yes, how do we do that? Do we have inlined-versions of these files? > Sounds messy. Can people run cpp separately on the files, then compile > them? I wonder. I think this is an SCO-only problem, and seeing as > their native compilers are notoriously buggy (Microsoft/SVr4 code), it > is no wonder. Well, those macros used to be a function call, right? So surround the macro with#ifdef USE_INLINING #define ... #endif and surround the old subroutine code with #ifndef USE_INLINING ... #endif Or are the macros of a different nature and not just a subroutine inlining? If there still needs to be a little macro expansion, then that could be done also... > The alpha problem has been solved by having a s_lock.c file, that only > contains the alpha/linux locking code. They don't have local asm > labels, and hence the workaround. I believe this is not a problem issue > for 6.3. Anyone? Of course, we still have the initdb problem, or do > we? Don't know...
В списке pgsql-hackers по дате отправления: