On Mon, Apr 09, 2001 at 11:41:55AM -0700, Henry B. Hotz wrote:
> At 1:50 AM -0400 4/6/01, Tom Lane wrote:
...
> >What version of libreadline do you have installed, and how does it
> >declare completion_matches()?
>
> I have whatever is standard on NetBSD 1.5. I noticed that configure
> found a
> At 1:50 AM -0400 4/6/01, Tom Lane wrote:
> >"Henry B. Hotz" <[EMAIL PROTECTED]> writes:
> > > Bottom line: 7.1RC1 passes most of the regression tests on
> > > NetBSD/macppc.
> >
> >The only thing that surprised me here was all of the warnings from
> >libreadline calls:
> >
> > >> tab-complete.
At 1:50 AM -0400 4/6/01, Tom Lane wrote:
>"Henry B. Hotz" <[EMAIL PROTECTED]> writes:
> > Bottom line: 7.1RC1 passes most of the regression tests on
> > NetBSD/macppc.
>
>The only thing that surprised me here was all of the warnings from
>libreadline calls:
>
> >> tab-complete.c: In function `ini
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> On such a platform it would hardly be possible to detect anything with any
> reliably. A linker that links a program "succesfully" while the program
> really needs more libraries to be runnable isn't very useful.
You're right, of course -- it's a b
Tom Ivar Helbekkmo writes:
> Giles Lean <[EMAIL PROTECTED]> writes:
>
> > It is still necessary to add -ltermcap after -ledit in
> > src/Makefile.global to have functional history editing in psql.
>
> This is a weakness in the configure script: it goes through a loop
> where it tries to link a pr
Giles Lean <[EMAIL PROTECTED]> writes:
> It is still necessary to add -ltermcap after -ledit in
> src/Makefile.global to have functional history editing in psql.
This is a weakness in the configure script: it goes through a loop
where it tries to link a program that calls readline() with, in ord
> If somethings happen this weekend, I *MAY* have a HP9000/433s (M68K)
> running NetBSD to play with
That would be great. I *know* that there are some m68k machines around
somewhere on this planet, and it would be a shame to not have NetBSD
tested for the release...
-
"Henry B. Hotz" <[EMAIL PROTECTED]> writes:
> Bottom line: 7.1RC1 passes most of the regression tests on
> NetBSD/macppc.
The only thing that surprised me here was all of the warnings from
libreadline calls:
>> tab-complete.c: In function `initialize_readline':
>> tab-complete.c:103: warning:
Tom Ivar Helbekkmo <[EMAIL PROTECTED]> writes:
> Also, dynamic loading now works on NetBSD/vax, so my old #ifdef for
> that in the backend/port/bsd.c file, which has since propagated into
> the new *bsd.c files, can go away.
Patch applied, thanks.
regards, tom lane
-
At 11:06 PM 3/28/01 -0500, Tom Lane wrote:
>Mark Knox <[EMAIL PROTECTED]> writes:
>> I don't think this solution would be valid on many other platforms.
>
>Au contraire --- the ARM is the first platform I've heard of that does
>not think sizeof(ItemPointerData) is 6. Else we'd have seen this
>reg
On Tue, 27 Mar 2001 09:57:45 -0500 (EST), Bruce Momjian alluded:
>
> We just fixed that yesterday. Can you grab the most recent CVS and give
> it a try?
Yep. We have many other MIPS (ONYX Crimson, , ONYX, Challenge, Indy w/ IRIX
6.2, 6.5, etc.), Alpha and Sparc platforms if there are some
Mark Knox <[EMAIL PROTECTED]> writes:
> Well, this patch seems to produce attlens of 6 as desired, but it
> causes many (13) of the regression tests to fail. Do you want to see
> the regression.diffs?
>>
>> Please.
> See attached.
Does look pretty broken, but I don't see how my idea would have
Mark Knox <[EMAIL PROTECTED]> writes:
> I don't think this solution would be valid on many other platforms.
Au contraire --- the ARM is the first platform I've heard of that does
not think sizeof(ItemPointerData) is 6. Else we'd have seen this
regress test fail before.
> Well, this patch seems
At 12:27 AM 3/28/01 -0500, Tom Lane wrote:
>That would fix it for ARM but not for anyplace else with similar
>alignment behavior. Would you try this patch instead to see what
>happens?
I don't think this solution would be valid on many other platforms. It forces the
structure to not be padded,
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> >> What gcc version does that platform have?
>
> > gcc version egcs-2.90.25 980302 (egcs-1.0.2 prerelease)
>
> Can you try a known-stable gcc version? 2.95.2 say?
I don't have time right know. Will do maybe for 7.1.1 or 7.2..
--
Tatsuo Ishii
--
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> What gcc version does that platform have?
> gcc version egcs-2.90.25 980302 (egcs-1.0.2 prerelease)
Can you try a known-stable gcc version? 2.95.2 say?
regards, tom lane
---(end of broadcast)--
> I think you've got a badly broken compiler there. There's no way that
> ExecReplace should be entered for a SELECT. The backtrace is wrong on
> its face anyway --- ExecutePlan does not call itself.
Yes, I have suspected that.
> What gcc version does that platform have?
gcc version egcs-2.90
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii
> If compiled with -O2 or -O2 -g, I got 10 tests FAILED. misc test
> failed due to a backend crash. The SQL caused the crash was:
> select i, length(t), octet_length(t), oldstyle_length(i,t) from
> oldst
"Mark Knox" <[EMAIL PROTECTED]> writes:
> {
> BlockIdData ip_blkid;
> OffsetNumber ip_posid;
> +#ifdef __arm__
> +} __attribute__((packed)) ItemPointerData;
> +#else
> }
> +#endif
That would fix it for ARM but not for anyplace else with similar
alignment behavior. Would you try thi
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your s
-BEGIN PGP SIGNED MESSAGE-
On 27 Mar 2001, at 20:49, Mark Knox wrote:
> > > I suspect it might be an alignment problem
> >
> > Sort of. I am suspicious that sizeof(ItemPointerData) is returning
> > 8 rather than 6 as one might expect.
>
> Maybe it's padding the structure to a dword bo
-BEGIN PGP SIGNED MESSAGE-
On 26 Mar 2001, at 23:14, Tom Lane wrote:
> "Mark Knox" <[EMAIL PROTECTED]> writes:
> > On 25 Mar 2001, at 16:07, Tom Lane wrote:
> >> Does that database have any user-created relations in it, or is it
> >> just a virgin database?
>
> > Totally virgin. I creat
> > mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii
> >
> > Any luck with RC1?
>
> I will try today or tomorrow...
In summary no, improvemnets seen.
If compiled with -O2 or -O2 -g, I got 10 tests FAILED. misc test
failed due to a backend crash. The SQL caused the crash was:
select i, length(t
Tom Ivar Helbekkmo <[EMAIL PROTECTED]> wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo
> Fetching the latest source kit now -- hope to have regression tests
> run and a report back to you within a day or two.
>> We need some NetBSD fol
Mathijs Brands <[EMAIL PROTECTED]> writes:
> Even if you fix this it won't work (I tried it). Robert mailed
> why. Check the URL below for more information. It crashes on semctl :(
> http://freeware.sgi.com/shared/howto.html#b1
Ugh. Given the semctl compatibility problem, I suspect we'd better
"Mayers, Philip J" <[EMAIL PROTECTED]> writes:
> I've already reported this to the webpage, but I got a fail on the random
> test:
> random ... failed (ignored)
See
http://www.postgresql.org/devel-corner/docs/postgres/regress.html
especially the last item ...
On Tue, Mar 27, 2001 at 09:57:45AM -0500, Bruce Momjian allegedly wrote:
> We just fixed that yesterday. Can you grab the most recent CVS and give
> it a try?
Even if you fix this it won't work (I tried it). Robert mailed why. Check the URL below
for more information. It crashes on semctl :(
ht
I've already reported this to the webpage, but I got a fail on the random
test:
random ... failed (ignored)
This is on a stock RedHat 7.0 kernel box with the SMP kernel (but running a
single processor):
[pjm3@localhost regress]$ less regression.diffs
*** ./expected/random.out
Mathijs Brands writes:
> I just tried to compile 7.1RC1 on my IRIX 6.5 box using gcc 2.95.2.
According to the information at
http://freeware.sgi.com/shared/howto.html#b1 it probably won't work to
compile PostgreSQL with GCC on Irix. Or it might work and crash when run.
Be warned. (I think it i
Jeff Duffy <[EMAIL PROTECTED]> writes:
> s_lock.c:235: parse error before `_volatile__'
That typo is fixed in current sources (should be OK in last night's
snapshot) but there's still some doubt as to how well the MIPS assembly
code works ...
regards, tom lane
--
We just fixed that yesterday. Can you grab the most recent CVS and give
it a try?
> One that didn't compilei RC1:
>
> BIGBOY 71# uname -a
> IRIX BIGBOY 6.5 05190003 IP22
>
> On an Indigo2 (R4000), gcc 2.95.2 , with the following error:
>
> gcc -Wall -Wmissing-prototypes -Wmissing-declarati
-BEGIN PGP SIGNED MESSAGE-
On 25 Mar 2001, at 16:07, Tom Lane wrote:
> Does that database have any user-created relations in it, or is it
> just a virgin database? It seems that the wrong attlen is being
> computed for ctid fields during bootstrap, but the regression test
> output (if i
On Tue, Mar 27, 2001 at 06:36:37AM -0500, D'Arcy J.M. Cain allegedly wrote:
> Thus spake Tom Ivar Helbekkmo
> > > We need some NetBSD folks to speak up!
>
> I have successfully compiled it from CVS sources on my NetBSD -current but
> I can't find the tar file for RC1 to try it with the package sy
Thus spake Tom Ivar Helbekkmo
> > We need some NetBSD folks to speak up!
I have successfully compiled it from CVS sources on my NetBSD -current but
I can't find the tar file for RC1 to try it with the package system. Can
someone point me to it please.
--
D'Arcy J.M. Cain| Democracy is thr
"Mark Knox" <[EMAIL PROTECTED]> writes:
> On 25 Mar 2001, at 16:07, Tom Lane wrote:
>> Does that database have any user-created relations in it, or is it
>> just a virgin database?
> Totally virgin. I created it just for that select you wanted.
Okay. Would you create a couple of random tables
Mathijs Brands <[EMAIL PROTECTED]> writes:
> Notice the single underscore before volatile.
That's definitely wrong --- fixed.
> Fixing this causes
> as (the SGI version, not GNU as) to choke on the '.global tas' statement.
> s_lock.c: At top level:
> s_lock.c:234: warning: `tas_dummy' defined b
At 7:53 PM -0500 3/26/01, Tom Lane wrote:
>Thomas Lockhart <[EMAIL PROTECTED]> writes:
>>> "PPC750"? What's that? "PPC G3" might be more likely to mean something
>>> to onlookers ...
>
>> Actually "G3" means nothing outside of Apple afaict. The 750 series is a
>> follow-on to the 60x series, and
On Mon, Mar 26, 2001 at 07:09:38PM -0500, Tom Lane allegedly wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > That is not already available from the Irix support code?
>
> What we have for IRIX is
>
> #if defined(__sgi)
> /*
> * SGI IRIX 5
> * slock_t is defined as a unsigned long. We
On Tue, Mar 27, 2001 at 12:01:24PM +1000, Justin Clift allegedly wrote:
> I know that Sourceforge has been adding all sorts of machines to their
> compile farm.
>
> Maybe it would be worthwhile taking a look if they have platforms we
> don't?
>
> Regards and best wishes,
>
> Justin Clift
Compa
I know that Sourceforge has been adding all sorts of machines to their
compile farm.
Maybe it would be worthwhile taking a look if they have platforms we
don't?
Regards and best wishes,
Justin Clift
Thomas Lockhart wrote:
>
> > The non-test-and-set case should work again in current CVS, and I
Hi,
I tested Solaris 8 SPARC (32 bit) over the weekend, and can test Solaris
8 INTEL this week/weekend.
The results of Solaris 8 SPARC were in Vince's database last time I
checked. ???
+ Justin
Mathijs Brands wrote:
>
> Hi
>
> Is there a list somewhere listing the platforms 7.1 is being
> t
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> "PPC750"? What's that? "PPC G3" might be more likely to mean something
>> to onlookers ...
> Actually "G3" means nothing outside of Apple afaict. The 750 series is a
> follow-on to the 60x series, and there is a 7xxx series also. From my
> pov, usi
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> That is not already available from the Irix support code?
What we have for IRIX is
#if defined(__sgi)
/*
* SGI IRIX 5
* slock_t is defined as a unsigned long. We use the standard SGI
* mutex API.
*
* The following comment is left for historical
> The non-test-and-set case should work again in current CVS, and I'd
> appreciate it if Alexander would verify that. But as far as getting
> some test-and-set support for MIPS goes, it looks like the only way
> is for someone to sit down with a MIPS assembly manual. I haven't
> got one, nor acc
On Mon, Mar 26, 2001 at 06:35:59PM -0500, Tom Lane allegedly wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> >> Anyway, the last CVS update to port/ultrix.h that appears to have come
> >> from someone actually using Ultrix was rev 1.2 on 7-May-97, which
> >> predates the very existence of s
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> Anyway, the last CVS update to port/ultrix.h that appears to have come
>> from someone actually using Ultrix was rev 1.2 on 7-May-97, which
>> predates the very existence of s_lock.h as a separate file. So I'd
>> definitely advise Alexander to find a
Trond Eivind Glomsrød wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Did you get the message from Trond about Linux 2.4 x86? I can also
> > verify all tests passed on a RedHat Public Beta installation with kernel
> > 2.4.
> I haven't put those in the list yet... I'll wait until we release
On Mon, Mar 26, 2001 at 05:41:31PM -0500, Vince Vielhaber allegedly wrote:
> On Tue, 27 Mar 2001, Mathijs Brands wrote:
> > Hi
> >
> > Is there a list somewhere listing the platforms 7.1 is being
> > tested on right now? I'd be able to run regression tests on
> > the following platforms, if necess
On Tue, 27 Mar 2001, Mathijs Brands wrote:
> Hi
>
> Is there a list somewhere listing the platforms 7.1 is being
> tested on right now? I'd be able to run regression tests on
> the following platforms, if necessary:
>
> FreeBSD 3.3 (x86)
> FreeBSD 4.2 (x86)
> Linux (x86 - 2.2 & 2.4 kernels
> Did you get the message from Trond about Linux 2.4 x86? I can also
> verify all tests passed on a RedHat Public Beta installation with kernel
> 2.4.
Trond had indicated that it was a 2.4.2 kernel with lots 'o patches, so
I figured I'd show the released stuff for now. I mentioned 2.4.2 in the
c
Lamar Owen <[EMAIL PROTECTED]> writes:
> Thomas Lockhart wrote:
> > Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick
> > Linux 2.2.x armv4l 7.1 2001-03-22, Mark Knox
> > Linux 2.2.18 PPC750 7.1 2001-03-19, Tom Lane
> > Linux 2.2.x S/390 7.1 2000-11-17, Neale Ferguson
> > Linux 2.2.15 Sparc 7.
Thomas Lockhart wrote:
> Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick
> Linux 2.2.x armv4l 7.1 2001-03-22, Mark Knox
> Linux 2.2.18 PPC750 7.1 2001-03-19, Tom Lane
> Linux 2.2.x S/390 7.1 2000-11-17, Neale Ferguson
> Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick
> Linux 2.2.16 x86
Hi
Is there a list somewhere listing the platforms 7.1 is being
tested on right now? I'd be able to run regression tests on
the following platforms, if necessary:
FreeBSD 3.3 (x86)
FreeBSD 4.2 (x86)
Linux (x86 - 2.2 & 2.4 kernels, Redhat & Debian distro's)
Solaris 7 (SPARC)
Solaris 8 (
Karl DeBisschop <[EMAIL PROTECTED]> writes:
> In my tests on sparc/7 my compile died at line 3088 of
> postgresql-7.1beta6/src/interfaces/python/pgmodule.c:
> ./pgmodule.c:3088: parse error before `init_pg'
> That's line 3137 of today's (22Mar) snapshot, which reads:
> /* Initialization functio
75044-6749 US
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 3/26/01, 2:36:19 PM, Thomas Lockhart <[EMAIL PROTECTED]> wrote
regarding Re: [HACKERS] Re: Call for platform
> > > > SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie
> > > Where did you see this? I don't find it in the archives or in Vince's
> > > database.
> > In FAQ_SCO. I was looking to try to figure out what the differences were
> > between the SCO products :)
> I wouldn't necessarily count someth
> > As mentioned earlier, Ultrix on RISC means that it is a MIPS processor.
> > Any hints for Alexander on how to do it *if* it is a MIPS processor?
> Not sure. The only info I see in s_lock.h is in the "SGI" section:
> * This stuff may be supplemented in the future with Masato Kataoka's MIPS-II
> "PPC750"? What's that? "PPC G3" might be more likely to mean something
> to onlookers ...
Actually "G3" means nothing outside of Apple afaict. The 750 series is a
follow-on to the 60x series, and there is a 7xxx series also. From my
pov, using an accepted label, rather than a marketing (re)la
Thomas Lockhart writes:
> > > SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie
> > Where did you see this? I don't find it in the archives or in Vince's
> > database.
>
> In FAQ_SCO. I was looking to try to figure out what the differences were
> between the SCO products :)
I wouldn't necessar
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> As mentioned earlier, Ultrix on RISC means that it is a MIPS processor.
>> I suspect that some one of the implementations in s_lock.h was intended
>> to be usable on Ultrix, and we've somehow dropped the declarations
>> needed to make it go. You migh
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Linux 2.2.18 PPC750 7.1 2001-03-19, Tom Lane
"PPC750"? What's that? "PPC G3" might be more likely to mean something
to onlookers ...
regards, tom lane
---(end of broadcast)---
ver.
LER
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 3/26/01, 12:05:55 PM, Thomas Lockhart <[EMAIL PROTECTED]>
wrote regarding Re: [HACKERS] Re: Call for platforms:
> > SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie
> Where did you see this? I don't find it in the archives or in Vince's
> database.
In FAQ_SCO. I was looking to try to figure out what the differences were
between the SCO products :)
- Thomas
--
Thomas Lockhart writes:
> SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie
Where did you see this? I don't find it in the archives or in Vince's
database.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)-
> >> Suddenly I obtain access to
> >> ULTRIX black 4.3 1 RISC
> > Uh ... what kind of processor is that? Offhand I don't see any
> > indication that any of the entries in s_lock.h are supposed to work
> > for Ultrix.
As mentioned earlier, Ultrix on RISC means that it is a MIPS processor.
DEC imp
-BEGIN PGP SIGNED MESSAGE-
On 25 Mar 2001, at 15:02, Tom Lane wrote:
> > (rounding on the final digit) and this rather troubling output from
> > type_sanity.
>
> Most bizarre --- and definitely indicative of trouble. Would you send
> along the output of this query in that database:
>
Does that database have any user-created relations in it, or is it
just a virgin database? It seems that the wrong attlen is being
computed for ctid fields during bootstrap, but the regression test
output (if it was complete) implies that the value inserted for
user-created fields was OK. This d
"Mark Knox" <[EMAIL PROTECTED]> writes:
>> Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox
> Compiled and tested 7.1beta6 tonight. All the regression tests passed
> except two - the usual minor differences in geometry (rounding on the
> final digit) and this rather troubling output from type_sanit
The Hermit Hacker wrote:
>
> On Thu, 22 Mar 2001, Thomas Lockhart wrote:
>
> > Solaris x867.0 2000-04-12, Marc Fournier
> >
> > scrappy, do you still have this machine?
>
> Doing tests on Solaris x86/7 right now, will report as soon as they are
> done ...
>
> > Solaris 2.5.1-2.7 Sparc
> Alexander Klimov <[EMAIL PROTECTED]> writes:
>> Suddenly I obtain access to
>> ULTRIX black 4.3 1 RISC
> Uh ... what kind of processor is that? Offhand I don't see any
> indication that any of the entries in s_lock.h are supposed to work
> for Ultrix.
On closer look I notice that the putativ
Tom Lane <[EMAIL PROTECTED]> writes:
> Alexander Klimov <[EMAIL PROTECTED]> writes:
> > Suddenly I obtain access to
> > ULTRIX black 4.3 1 RISC
>
> Uh ... what kind of processor is that? Offhand I don't see any
> indication that any of the entries in s_lock.h are supposed to work
> for Ultrix.
Alexander Klimov <[EMAIL PROTECTED]> writes:
> Suddenly I obtain access to
> ULTRIX black 4.3 1 RISC
Uh ... what kind of processor is that? Offhand I don't see any
indication that any of the entries in s_lock.h are supposed to work
for Ultrix.
regards, tom lane
---
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
> =
> 1 of 76 tests failed, 1 failed test(s) ignored.
> =
>>
>> That's just ye olde random "random" failure ...
> Actually, this is one
Tom Lane writes:
> > and yet another run (and different results):
>
> > =
> > 1 of 76 tests failed, 1 failed test(s) ignored.
> > =
>
> That's just ye olde random "random" failure ...
Actually, this
bpalmer <[EMAIL PROTECTED]> writes:
> seconds. Most of the time is spent in this test:
> parallel group (13 tests): float4 int2 int4 text name varchar oid boolean
> char float8 int8 bit numeric
> There is a long pause between 'bit' and 'numeric'. Same with on i386. Is
> this a problem that i
> OpenBSD 2.8 x867.1 2001-03-22, Brandon. Palmer
OBSD checks out for sparc and i386. We did need to make a change to the
resultmap file to make the regression tests clean for the sparc. I have
attached the diff.
Also, on the sparc that i'm using (sparc4/110), make check takes 1950
se
> > I have tested today's snap shot on SunOS4.
> > For the regression test, I got 7 failures, most of them seem harmless,
> > the only concern I have is bit test though.
> > P.S. I'm going to test Linux/MIPS (Cobalt RaQ2) soon...
>
> Great! I'll update info for SunOS4 (individual problems will
On Thu, 22 Mar 2001, Patrick Welche wrote:
> On Thu, Mar 22, 2001 at 12:49:39PM -0500, Tom Lane wrote:
> > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > >> These are parallel tests right? What's the failure diffs?
> >
> > > same as last time:
> >
> > > dragon:/home/centre/marc/src/postgresql
> NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean
Correction: NetBSD-1.5/alpha.
Ciao,
Giles
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
On Thu, Mar 22, 2001 at 12:49:39PM -0500, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> >> These are parallel tests right? What's the failure diffs?
>
> > same as last time:
>
> > dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more
> > results/opr_sanity.ou
> > NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean
> Correction: NetBSD-1.5/alpha.
Right. That was a typo in transcribing my online copy of the sgml docs
to the email. I was hoping no one caught it, and didn't bother sending a
correction ;)
- Thomas
---(
The Hermit Hacker <[EMAIL PROTECTED]> writes:
>> These are parallel tests right? What's the failure diffs?
> same as last time:
> dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more
> results/opr_sanity.out
> psql: connectDBStart() -- connect() failed: Connection refused
>
On Thu, 22 Mar 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > the second time
> > failed *totally* different tests then the first run:
>
> > dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> grep
> > FAILED regression.out
> > opr_sanity ...
Thomas Lockhart writes:
> > > OpenBSD 2.8 x867.1 2001-03-22, B. Palmer (first name?)
> > Though it does work, like FBSD, there are some changes that need to be
> > made to the system. Need max proc / files changes and a kernel recompile
> > with SEMMNI and SEMMNS changes. Anywhere special
The Hermit Hacker writes:
> How much 'diviation' are we allowing for?
>
> Solaris x86/7 results, for example, in geometry.out, show a difference of:
>
> 1.53102359078377e-11,3 (expected)
> 1.53102359017709e-11,3 (results)
>
> or
>
> 3,-3.06204718156754e-11 (expected)
> 3,-3.06204718035418e-11 (re
On Thu, 22 Mar 2001, Thomas Lockhart wrote:
> OpenBSD 2.8 x867.1 2001-03-22, B. Palmer (first name?)
Though it does work, like FBSD, there are some changes that need to be
made to the system. Need max proc / files changes and a kernel recompile
with SEMMNI and SEMMNS changes. Anywhere sp
The Hermit Hacker writes:
> > Is Solaris-x86 ready to go then?
>
> Nope, still working through some things ... the select_implicit test
> failed completely:
>
> dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more
>results/select_implicit.out
> psql: connectDBStart() -- connect(
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> the second time
> failed *totally* different tests then the first run:
> dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> grep
> FAILED regression.out
> opr_sanity ... FAILED
> join ... FAILED
>
On Thu, 22 Mar 2001, Thomas Lockhart wrote:
> > > OpenBSD 2.8 x867.1 2001-03-22, B. Palmer (first name?)
> > Though it does work, like FBSD, there are some changes that need to be
> > made to the system. Need max proc / files changes and a kernel recompile
> > with SEMMNI and SEMMNS change
On Thu, 22 Mar 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > Nope, still working through some things ... the select_implicit test
> > failed completely:
>
> > dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more
>results/select_implicit.out
> > psql:
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Nope, still working through some things ... the select_implicit test
> failed completely:
> dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more
>results/select_implicit.out
> psql: connectDBStart() -- connect() failed: Connection
> > OpenBSD 2.8 x867.1 2001-03-22, B. Palmer (first name?)
> Though it does work, like FBSD, there are some changes that need to be
> made to the system. Need max proc / files changes and a kernel recompile
> with SEMMNI and SEMMNS changes. Anywhere special to note this?
So more-or-less t
On Thu, 22 Mar 2001, Thomas Lockhart wrote:
> > Solaris x86/7 results, for example, in geometry.out, show a difference of:
> > 3,-3.06204718156754e-11 (expected)
> > 3,-3.06204718035418e-11 (results)
> > acceptable diviation?
>
> That sort of deviation is well within bounds, particularly for geom
4.3 is in RELEASE CANDIDATE right now. By the time we release, it should
be -RELEASE or -STABLE.
I'd include it as just 4.3.
It will be the -RELEASE at the time we are.
LER
>> Original Message <<
On 3/22/01, 8:50:26 AM, Thomas Lockhart <[EMAIL PROTECTED]>
> Solaris x86/7 results, for example, in geometry.out, show a difference of:
> 3,-3.06204718156754e-11 (expected)
> 3,-3.06204718035418e-11 (results)
> acceptable diviation?
That sort of deviation is well within bounds, particularly for geometry
tests which might have some transcendental math inv
How much 'diviation' are we allowing for?
Solaris x86/7 results, for example, in geometry.out, show a difference of:
1.53102359078377e-11,3 (expected)
1.53102359017709e-11,3 (results)
or
3,-3.06204718156754e-11 (expected)
3,-3.06204718035418e-11 (results)
acceptable diviation?
On Thu, 22 Ma
Thomas Lockhart writes:
> > SCO OpenServer 5 x86...
>
> OK, I see that Billy Allie recently updated FAQ_SCO to indicate
> demonstrated (?) support for OpenServer. I will reflect that in the
> platform support info.
The last FAQ_SCO update was by me, and it was rather the consequence of
some impl
97 matches
Mail list logo
