Re: [PATCHES] Reorganization of spinlock defines
От | Larry Rosenman |
---|---|
Тема | Re: [PATCHES] Reorganization of spinlock defines |
Дата | |
Msg-id | 87010000.1063338723@lerlaptop.lerctr.org обсуждение исходный текст |
Ответ на | Re: [PATCHES] Reorganization of spinlock defines (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCHES] Reorganization of spinlock defines
|
Список | pgsql-hackers |
--On Thursday, September 11, 2003 23:42:53 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: >> Looking at the code, I wonder if we already have folks not using >> spinlocks, and not even knowing it. I don't think problem reports will >> be limited to new platforms. > > Very likely --- I heard from someone recently who was trying to run > HPUX/Itanium. After we got past the hard-wired assumption that HPUX > == HPPA, it was still giving lousy performance for lack of spinlocks. > I like the part of the patch that is in-your-face about that. > >> I just learned from Larry that Unixware defines intel as i386, not >> __i386 or __i386__, at least of the native SCO compiler that he uses. > > [blink] Namespace infringement 'r us, huh? Yeah. I **DO** have SCO's ear on it, but I don't know how far I'll get, plus there are TONS of pre-whenever-we-get-it-fixed out there. > >> I am going to test for __cpu, __cpu__, and cpu on non-gcc compiler for >> consistency. It is only done in one place in the patch, so that should >> be good. > > Please, only the first two. Make the Unixware template add __i386__. > Don't add assumptions about valid user-namespace symbols. that's reasonable. At least until 64-bit UnixWare. :-) (announced at SCOForum). > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
В списке pgsql-hackers по дате отправления: