huia and moa versus old PG branches
От | Tom Lane |
---|---|
Тема | huia and moa versus old PG branches |
Дата | |
Msg-id | 3421.1283136659@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: huia and moa versus old PG branches
Re: huia and moa versus old PG branches |
Список | pgsql-hackers |
The new buildfarm machines huia and moa aren't doing terribly well with the older PG branches. This isn't really those machines' fault; what I find after a bit of digging is that we just didn't have good support for 64-bit Solaris until relatively recently. In particular: * There was no 64-bit spinlock assembler code that worked with Sun's compiler until 8.2. The first attempt to support it was here: http://archives.postgresql.org/pgsql-committers/2005-12/msg00507.php although that got whacked around quite a bit before 8.2 final. * gcc builds didn't fully work in 64-bit Solaris either until 8.3: http://archives.postgresql.org/pgsql-committers/2007-01/msg00154.php Before that patch, contrib didn't build because pgcrypto needs BYTE_ORDER to be defined. huia, which is claimed on the buildfarm dashboard to be using Sun Studio but is actually using gcc, thus fails at the contrib make stage before 8.3. moa, which is claimed on the buildfarm dashboard to be using gcc but is actually using cc, hits the spinlock problem in 8.0 and 8.1 and the BYTE_ORDER problem in 8.2. That BYTE_ORDER patch is pretty small and safe, so I think it would be reasonable to back-patch it into 8.2 so that we have a uniform story that 64-bit Solaris is supported in 8.2 and up. The spinlock changes were significantly more invasive, so my feeling is we should not try to back-patch them, but just turn off moa for pre-8.2 branches. Also, although moa is actually green for 8.3, it's showing an initdb failure in 8.4 and up ("cache lookup failed for type 0" while processing system_views.sql). I'm betting this is some sort of over-aggressive-optimization problem, but it's hard to tell much from the buildfarm logs. Could you look into that and find out exactly where it's failing? regards, tom lane
В списке pgsql-hackers по дате отправления: