Re: What is happening on buildfarm member baiji?
От | Andrew Dunstan |
---|---|
Тема | Re: What is happening on buildfarm member baiji? |
Дата | |
Msg-id | 464783E2.2090402@dunslane.net обсуждение исходный текст |
Ответ на | Re: What is happening on buildfarm member baiji? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: What is happening on buildfarm member baiji?
|
Список | pgsql-hackers |
Tom Lane wrote: > "Andrew Dunstan" <andrew@dunslane.net> writes: > >> Unless that has somehow got screwed up I can't see how Tom's theory of a >> possibly left over .bki file can stand up. >> > > Well, I tried inserting a .bki file from April 30 into a HEAD > installation, and that made it dump core during bootstrap, so that > offhand theory was wrong. > > However, when I run the HEAD regression tests against that entire > April 30 installation tree, I can duplicate the baiji regression diffs > almost exactly --- the polymorphism test fails for me where it succeeds > on baiji, which I think indicate that baiji has the patch I applied on > May 1 for SQL function inlining. > > So I now state fairly confidently that baiji is failing to overwrite > *any* of the installation tree, /share and /bin both, and instead is > testing an installation dating from sometime between May 1 and May 11. > Have there been any recent changes in either the buildfarm script or > the MSVC install code that might have changed where the install is > supposed to go? > > Not to my knowledge, but I have no method of testing what's going on, and I hate guessing like this - in fact this is what has worried me all along about supporting MSVC builds - we always said we didn't want to have to have 2 build environments, but now we have two and we'll be supporting them forever, even though one of them is not used by 95% of our developers. I realise that MSVC builds are likely to perform better, but we have now got a situation where we are likely to have breakage on a regular basis, ISTM. (sorry to grumble - it's been a very frustrating 24 hours) cheers andrew
В списке pgsql-hackers по дате отправления: