On Jan 31, 2008 1:33 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Re-reading the thread ... could that last point be significant? Are
all four of these boxen set to auto-accept updates from Redmond?
No. red_bat does not auto-accept anything.
For future reference, my BF members do
On Thu, Jan 31, 2008 at 08:28:21AM +, Dave Page wrote:
On Jan 31, 2008 1:33 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Re-reading the thread ... could that last point be significant? Are
all four of these boxen set to auto-accept updates from Redmond?
No. red_bat does not
On Thu, Jan 31, 2008 at 12:45:40AM -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Yes, I have found the problem. It is this line, which I am amazed hasn't
bitten us before:
next unless /^\d/;
The first field in the dumpbin output looks like a 3 digit hex number.
Magnus Hagander wrote:
I also propose to have the gendefs.pl script save the dumpbin output so
this sort of problem will be easier to debug.
Agreed, but I suggest waiting till 8.4 is branched unless you are really
sure about this addition. We freeze for 8.3.0 in less than 24 hours.
Magnus Hagander [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
For now I'm going try to fix it by changing it to:
next unless $pieces[0] =~/^[A-F0-9]{3}$/;
Yeah, nice catch. Wouldn't surprise me if we actually had this problem
before, just that the dropped symbols were
Andrew Dunstan [EMAIL PROTECTED] writes:
Agreed, but I suggest waiting till 8.4 is branched unless you are really
sure about this addition. We freeze for 8.3.0 in less than 24 hours.
I am pretty damn sure it's OK. It's pretty low risk (change an unlink
call to a rename call) and even if
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
For now I'm going try to fix it by changing it to:
next unless $pieces[0] =~/^[A-F0-9]{3}$/;
Yeah, nice catch. Wouldn't surprise me if we actually had this problem
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Agreed, but I suggest waiting till 8.4 is branched unless you are really
sure about this addition. We freeze for 8.3.0 in less than 24 hours.
I am pretty damn sure it's OK. It's pretty low risk (change an unlink
call
http://msdn2.microsoft.com/en-us/library/b842y285(VS.71).aspx
appears to
suggest that the size of the field is fixed.
That would imply that dumpbin fails at 4096 symbols per file. While I
surely wouldn't put it past M$ to have put in such a
limitation, I think
it's more likely that
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
It strikes me that the pattern needs to be {3,} or maybe just +.
I dunno what this column is measuring, but if we are past 0xA00
then surely 0x1000 is not far away.
http://msdn2.microsoft.com/en-us/library/b842y285(VS.71).aspx appears
Zeugswetter Andreas ADI SD wrote:
http://msdn2.microsoft.com/en-us/library/b842y285(VS.71).aspx
appears to
suggest that the size of the field is fixed.
That would imply that dumpbin fails at 4096 symbols per file. While I
surely wouldn't put it past M$ to have put in such a
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2008-01-30%2020:00:00
/D
---(end of broadcast)---
TIP 6: explain analyze is your friend
Dave Page wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2008-01-30%2020:00:00
Maybe I shouldn't have had those beers after work today, but that looks
like it's for example failing tsearch2, which hasn't been touched for
over a month!
Any chance there's something dodgy
Dave Page wrote:
On Jan 30, 2008 9:13 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Dave Page wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2008-01-30%2020:00:00
Maybe I shouldn't have had those beers after work today, but that looks
like it's for example failing
On Jan 30, 2008 9:21 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
I won't have access to my MSVC box until tomorrow, but unless beaten to
it I can dig into it a bit more. I don't see anything obvious int he
latest patches thoughy (but again, that could be the beer :-P).
Any chance you could
On Jan 30, 2008 9:13 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Dave Page wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2008-01-30%2020:00:00
Maybe I shouldn't have had those beers after work today, but that looks
like it's for example failing tsearch2, which hasn't
Dave Page wrote:
On Jan 30, 2008 9:13 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Dave Page wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2008-01-30%2020:00:00
Maybe I shouldn't have had those beers after work today, but that looks
like it's for example
Andrew Dunstan [EMAIL PROTECTED] writes:
None of the CVS changes in the relevant period seems to have any
relation to the errors, so I suspect a local problem.
skylark and baiji are now red too, so I guess that theory is dead in the
water. Something in today's changes broke the MSVC build,
I wrote:
I diffed yesterday's and today's make logs from skylark, and found
nothing interesting except this:
***
*** 605,611
Generating POSTGRES.DEF from directory Release\postgres^M
! Generated 5208 symbols^M
Linking...^M
--- 605,611
Dave Page [EMAIL PROTECTED] writes:
I can't remember the last time I logged into that box so if it's
something in the buildenv, it's either caused by a Windows update,
Re-reading the thread ... could that last point be significant? Are
all four of these boxen set to auto-accept updates from
Tom Lane wrote:
* Has the buildfarm script changed recently in a way that might change
the execution PATH and thereby suck in a different version of dumpbin?
(Or even a different version of Perl?)
No. In at least the case of red_bat nothing has changed for months.
* Is it conceivable
Tom Lane wrote:
Neither of these sound very plausible, but it seems the next step for
investigation is to look closely at what's happening in gendef.pl.
Yes, I have found the problem. It is this line, which I am amazed hasn't
bitten us before:
next
Andrew Dunstan [EMAIL PROTECTED] writes:
Yes, I have found the problem. It is this line, which I am amazed hasn't
bitten us before:
next unless /^\d/;
The first field in the dumpbin output looks like a 3 digit hex number.
Argh, so it was crossing a power-of-2 boundary that got us.
23 matches
Mail list logo