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
On Fri, Apr 13, 2001 at 01:25:45PM +, Thomas Lockhart wrote:
> > Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's
> > patch should be applied?
>
> I'm unclear on what y'all mean by "i386 + fpu", especially since NetBSD
> seems to insist on calling every Intel proces
> Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's
> patch should be applied?
I'm unclear on what y'all mean by "i386 + fpu", especially since NetBSD
seems to insist on calling every Intel processor a "i386". In this case,
are you suggesting that this patch covers all N
> 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
> Thanks! I'm not too worried about 1.4.2, but be sure to let us know what
> the problem was; it may help out someone else...
NetBSD-1.4.2/i386 passes all tests with 7.1RC3.
My previous test failure on this platform was due to the timezone
information on the test system not being standard; once
> 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:
> Bottom line: 7.1RC1 passes most of the regression tests on
> NetBSD/macppc. It's probably good enough for normal use since the
> differences are not extensive, but someone would need to look at the
> diff's for longer than the 10 seconds or so I've spent so far, and
> someone should actually s
Bottom line: 7.1RC1 passes most of the regression tests on
NetBSD/macppc. It's probably good enough for normal use since the
differences are not extensive, but someone would need to look at the
diff's for longer than the 10 seconds or so I've spent so far, and
someone should actually set it
> > I've once again got a VAX that should be able to run PostgreSQL on
> > NetBSD/vax, so I hope to be able to help revitalize that port soon...
> It still works. RC1 configures, compiles and runs on my VAX 4000/500
> with NetBSD-current -- but the regression tests give a lot of failures
> becaus
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
-
Tom Ivar Helbekkmo <[EMAIL PROTECTED]> writes:
> > We need some NetBSD folks to speak up!
>
> I've once again got a VAX that should be able to run PostgreSQL on
> NetBSD/vax, so I hope to be able to help revitalize that port soon...
It still works. RC1 configures, compiles and runs on my VAX 4
> 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 others that need
> testing (How about NetBSD on NeXT?).
All of these are interesting to help others decide whether their
particular machine is supported.
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
I wrote:
> > 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.
Hmm. No go here: everything looks peachy until I've started the
postmaster, and attempt to connect to it:
"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
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-declarations
-I../../../../src/include -U_NO_XOPEN4 -c s_lock.c -o s_lock.o
s_lock.c: In function `s_lock':
-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
At 5:14 PM + 3/26/01, Thomas Lockhart wrote:
>NetBSD m68k7.0 2000-04-10, Henry B. Hotz
I no longer have a 68k machine that's fast enough to reasonably test
PG on. I have a IIcx that sometimes serves as a router, but I'm
using some second-generation powermac's mostly now. (You sti
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
> mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii
>
> Any luck with RC1?
I will try today or tomorrow...
--
Tatsuo Ishii
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMA
"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
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 folks to speak up!
I've once again got a VAX that should
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
> >NetBSD m68k7.0 2000-04-10, Henry B. Hotz
> I no longer have a 68k machine that's fast enough to reasonably test
> PG on. I have a IIcx that sometimes serves as a router, but I'm
> using some second-generation powermac's mostly now. (You still have
> that Centris in your closet Tom?)
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
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:
http://www.postgresql.org/devel-corner/docs/admin/supported-platforms.html
is close to up to date
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)-
The list of unreported or "in progress" platforms has gotten much
shorter. If anyone can help on the remaining problems, we'll be able to
move closer to release status, which is A Good Thing (tm) ;)
btw, if we get most of these qualified, we will be on around 30
platforms
-
> >> 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
-BEGIN PGP SIGNED MESSAGE-
On 22 Mar 2001, at 14:29, Thomas Lockhart wrote:
> 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
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
---
Hi all.
Suddenly I obtain access to
ULTRIX black 4.3 1 RISC
I don't shure is it supported, but I see /src/include/port/ultrix4.h file
so my guess is `yes, at least was'. I got last version from CVS and try
configure && gmake
it results in
gcc -Wall -Wmissing-prototypes -Wmissing-declarations
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
> 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 be fixed or
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
---(
1 - 100 of 122 matches
Mail list logo
