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
lim
> 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 like
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
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
b
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
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 ev
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 sy
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.
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 he
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
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 au
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
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 unle
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 t
"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 fr
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 --
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,
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
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=mastodon&dt=2008-01-30%2020:00:00
Maybe I shouldn't have had those beers after work today, but that looks
like it's for examp
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=mastodon&dt=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 tsearc
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=mastodon&dt=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
Dave Page wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodon&dt=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
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodon&dt=2008-01-30%2020:00:00
/D
---(end of broadcast)---
TIP 6: explain analyze is your friend
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> I never actually tested if it crashes on mingw, but looking some more at it
>>> it really should - once one of these errors happen.
>
>> Hm. Much easier than that - the code is new in HEAD. 8.2 did
>> fprintf(stderr). And HEAD still
Magnus Hagander <[EMAIL PROTECTED]> writes:
>> I never actually tested if it crashes on mingw, but looking some more at it
>> it really should - once one of these errors happen.
> Hm. Much easier than that - the code is new in HEAD. 8.2 did
> fprintf(stderr). And HEAD still does that in at least o
Magnus Hagander <[EMAIL PROTECTED]> writes:
> I also found at least one other place in libpq where it still does
> fprintf(stderr). That should probably be fixed at the same time, right?
Yeah, we should be using the error message buffer if at all possible.
regards, tom lan
Magnus Hagander wrote:
> On Mon, Jul 23, 2007 at 10:28:57AM -0400, Tom Lane wrote:
>>> Given this, I'll go ahead and fix fe-connect to support PQExpBuffers,
>>> unless there are any objections.
>> I'm not against that, but I question what bug you've really found.
>
> I never actually tested if it
On Mon, Jul 23, 2007 at 10:28:57AM -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > When run in debug mode, the runtime for msvc will *zero-pad the entire
> > buffer* in a strncpy() call. This in itself is not bad (just slow), but it
> > shows a rather bad bug in libpq.
>
>
Magnus Hagander <[EMAIL PROTECTED]> writes:
> When run in debug mode, the runtime for msvc will *zero-pad the entire
> buffer* in a strncpy() call. This in itself is not bad (just slow), but it
> shows a rather bad bug in libpq.
[squint] That is the specified behavior of strncpy on every platform
I've been debugging some really weird crashes in libpq on win32, and I
think I've finally found the reason for the heap corruption that shows up
in msvc debug mode.
When run in debug mode, the runtime for msvc will *zero-pad the entire
buffer* in a strncpy() call. This in itself is not bad (just s
Ignore my previous post - for obvious reasons!!!
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Sorry about including the regression test changes in that last patch - just
ignore them.
Since sending in that last patch, I've fixed preproc.y to use 5 instead of 6
as the number of params to concatenate...
Chris
---(end of broadcast)---
TIP 2:
Vic <[EMAIL PROTECTED]> writes:
>> What version of PostgreSQL are you using ?
> PostgreSQL 7.0.0 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66
Evidently not a released version, but some beta, since this behavior was
changed before 7.0 release (cf. scan.l CVS log for 18-Mar-2000).
I *stron
> What version of PostgreSQL are you using ?
>
PostgreSQL 7.0.0 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66
>
> I believe this is fixed a long time ago.
If you don't want to upgrade just put spaces in
> > select myfield from mytable where myfield = -1
Ya - i don't want make upgra
Vic wrote:
> Hi
> I try this "construction" : select myfield from mytable where
> myfield=-1
> And get this:
> ERROR: Unable to identify an operator '=-' for types 'numeric' and
> 'int4'
What version of PostgreSQL are you using ?
I believe this is fixed a long time ago.
If you don't w
Hi
I try this "construction" : select myfield from mytable where
myfield=-1
And get this:
ERROR: Unable to identify an operator '=-' for types 'numeric' and
'int4'
You will have to retype this query using an explicit cast
I don't lik this!
Vic
---(end o
regression=# begin;
BEGIN
regression=# insert into rtest_t1 values(1,2);
INSERT 287918 1
regression=# select * from tenk1, tenk1 t2;
-- press ^C here
Cancel request sent
ERROR: Query was cancelled.
ERROR: Query was cancelled.
FATAL 2: elog: error during error recovery, giving up!
pqReadData() -
37 matches
Mail list logo
