SEO

The last two runs on baiji have failed at the installcheck stage,
with symptoms that look a heck of a lot like the most recent system
catalog changes haven't taken effect (eg, it doesn't seem to know
about pg_type.typarray). Given that the previous "check" step
passed, the most likely explanation seems to be that some part
of the "install" step failed --- I've not tried to reproduce the
behavior but it looks like it might be explained if the install
target's postgres.bki file was not getting overwritten. So we
have two issues: what exactly is going wrong (some new form of
Vista brain death no doubt), and why isn't the buildfarm script
noticing?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom Lane wrote:
> The last two runs on baiji have failed at the installcheck stage,
> with symptoms that look a heck of a lot like the most recent system
> catalog changes haven't taken effect (eg, it doesn't seem to know
> about pg_type.typarray). Given that the previous "check" step
> passed, the most likely explanation seems to be that some part
> of the "install" step failed --- I've not tried to reproduce the
> behavior but it looks like it might be explained if the install
> target's postgres.bki file was not getting overwritten. So we
> have two issues: what exactly is going wrong (some new form of
> Vista brain death no doubt), and why isn't the buildfarm script
> noticing?
>


The script will not even run if the install directory exists:

die "$buildroot/$branch has $pgsql or inst directories!"
if ((!$from_source && -d $pgsql) || -d "inst");

But the install process is different for MSVC. It could be that we are
screwing up there.

I no longer have an MSVC box, so I can't tell so easily ;-(

cheers

andrew




---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Andrew Dunstan wrote:
> Tom Lane wrote:
>> The last two runs on baiji have failed at the installcheck stage,
>> with symptoms that look a heck of a lot like the most recent system
>> catalog changes haven't taken effect (eg, it doesn't seem to know
>> about pg_type.typarray). Given that the previous "check" step
>> passed, the most likely explanation seems to be that some part
>> of the "install" step failed --- I've not tried to reproduce the
>> behavior but it looks like it might be explained if the install
>> target's postgres.bki file was not getting overwritten. So we
>> have two issues: what exactly is going wrong (some new form of
>> Vista brain death no doubt), and why isn't the buildfarm script
>> noticing?
>>
>
>
> The script will not even run if the install directory exists:
>
> die "$buildroot/$branch has $pgsql or inst directories!"
> if ((!$from_source && -d $pgsql) || -d "inst");
>
> But the install process is different for MSVC. It could be that we are
> screwing up there.

Uh, but that piece of code you're referring to is from the bulidfarm
code, right? Isn't it the same?


> I no longer have an MSVC box, so I can't tell so easily ;-(

Non-Vista MSVC boxes seem to pass fine (mastodon and skylark, for
example - skylark fails on something completely different, not fully
investigated yet, but looks to be a buildfarm problem rather than a
backend one), so I don't think it's the MSVC procedure alone that's the
cause of it.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Magnus Hagander wrote:
> Andrew Dunstan wrote:
>> Tom Lane wrote:
>>> The last two runs on baiji have failed at the installcheck stage,
>>> with symptoms that look a heck of a lot like the most recent system
>>> catalog changes haven't taken effect (eg, it doesn't seem to know
>>> about pg_type.typarray). Given that the previous "check" step
>>> passed, the most likely explanation seems to be that some part
>>> of the "install" step failed --- I've not tried to reproduce the
>>> behavior but it looks like it might be explained if the install
>>> target's postgres.bki file was not getting overwritten. So we
>>> have two issues: what exactly is going wrong (some new form of
>>> Vista brain death no doubt), and why isn't the buildfarm script
>>> noticing?
>>>
>>
>>
>> The script will not even run if the install directory exists:
>>
>> die "$buildroot/$branch has $pgsql or inst directories!"
>> if ((!$from_source && -d $pgsql) || -d "inst");
>>
>> But the install process is different for MSVC. It could be that we are
>> screwing up there.
>
> Uh, but that piece of code you're referring to is from the bulidfarm
> code, right? Isn't it the same?


Yes, but it might be that the MSVC install doesn't actually use that
location properly. Unfortunately, its logging is less than verbose, unlike
the standard install procedure.

>
>
>> I no longer have an MSVC box, so I can't tell so easily ;-(
>
> Non-Vista MSVC boxes seem to pass fine (mastodon and skylark, for
> example - skylark fails on something completely different, not fully
> investigated yet, but looks to be a buildfarm problem rather than a
> backend one), so I don't think it's the MSVC procedure alone that's the
> cause of it.
>
>

Possibly. My point was that I can't even investigate how MSVC is working
at all.

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Andrew Dunstan wrote:
> Magnus Hagander wrote:
>> Andrew Dunstan wrote:
>>> Tom Lane wrote:
>>>> The last two runs on baiji have failed at the installcheck stage,
>>>> with symptoms that look a heck of a lot like the most recent system
>>>> catalog changes haven't taken effect (eg, it doesn't seem to know
>>>> about pg_type.typarray). Given that the previous "check" step
>>>> passed, the most likely explanation seems to be that some part
>>>> of the "install" step failed --- I've not tried to reproduce the
>>>> behavior but it looks like it might be explained if the install
>>>> target's postgres.bki file was not getting overwritten. So we
>>>> have two issues: what exactly is going wrong (some new form of
>>>> Vista brain death no doubt), and why isn't the buildfarm script
>>>> noticing?
>>>>
>>>
>>> The script will not even run if the install directory exists:
>>>
>>> die "$buildroot/$branch has $pgsql or inst directories!"
>>> if ((!$from_source && -d $pgsql) || -d "inst");
>>>
>>> But the install process is different for MSVC. It could be that we are
>>> screwing up there.
>> Uh, but that piece of code you're referring to is from the bulidfarm
>> code, right? Isn't it the same?
>
>
> Yes, but it might be that the MSVC install doesn't actually use that
> location properly. Unfortunately, its logging is less than verbose, unlike
> the standard install procedure.
>
>>
>>> I no longer have an MSVC box, so I can't tell so easily ;-(
>> Non-Vista MSVC boxes seem to pass fine (mastodon and skylark, for
>> example - skylark fails on something completely different, not fully
>> investigated yet, but looks to be a buildfarm problem rather than a
>> backend one), so I don't think it's the MSVC procedure alone that's the
>> cause of it.
>>
>>
>
> Possibly. My point was that I can't even investigate how MSVC is working
> at all.

So what is it you're looking for, specifically, to help with that?

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Magnus Hagander wrote:
>> My point was that I can't even investigate how MSVC is working
>> at all.
>
> So what is it you're looking for, specifically, to help with that?
>
>

As a very bare minimum, we need to change the installation procedure to
log its destination.

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.

cheers

andrew


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Andrew Dunstan wrote:
> Magnus Hagander wrote:
>>> My point was that I can't even investigate how MSVC is working
>>> at all.
>> So what is it you're looking for, specifically, to help with that?
>>
>>
>
> As a very bare minimum, we need to change the installation procedure to
> log its destination.
>
> 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.

Just to be clear, are you looking for something as simple as this?

Index: Install.pm
================================================== =================
RCS file: /cvsroot/pgsql/src/tools/msvc/Install.pm,v
retrieving revision 1.14
diff -c -r1.14 Install.pm
*** Install.pm 25 Apr 2007 19:00:05 -0000 1.14
--- Install.pm 13 May 2007 15:21:51 -0000
***************
*** 35,41 ****
$conf = "release";
}
die "Could not find debug or release binaries" if ($conf eq "");
! print "Installing for $conf\n";

EnsureDirectories($target,
'bin','lib','share','share/timezonesets','share/contrib','doc',
'doc/contrib', 'symbols');
--- 35,41 ----
$conf = "release";
}
die "Could not find debug or release binaries" if ($conf eq "");
! print "Installing for $conf in $target\n";

EnsureDirectories($target,
'bin','lib','share','share/timezonesets','share/contrib','doc',
'doc/contrib', 'symbols');



//Magnus

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Magnus Hagander wrote:
> ! print "Installing for $conf in $target\n";
>
>
>

Looks like a good place to start, sure.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>> ! print "Installing for $conf in $target\n";
>>
>>
>
> Looks like a good place to start, sure.

Ok. Applied.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"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?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly