yes, this is a bug in netbsd-current that was introduced with about 5 month
ago with the new unified buffer cache system. it has been fixed.
thanks.
From: Chuck Silvers <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: CVS commit: syssrc
Date: Mon, 16 Apr 2001 17:37:44 +0300 (EEST)
Modu
Tom Ivar Helbekkmo <[EMAIL PROTECTED]> writes:
> I can verify, that with NetBSD-current on sparc, your test code works
> the way you want it to on local disk, but fails (in the way you've
> observed), if the target file is on an NFS-mounted file system.
FWIW, the test program succeeds (no error)
Tom Lane <[EMAIL PROTECTED]> writes:
> > I think this is indisputably a bug in (some versions of) NetBSD.
>
> I forgot to mention a possible contributing factor: the files involved
> were NFS-mounted, in the case I was looking at. So this may be an NFS
> problem more than a NetBSD problem. Any
I wrote:
> I think this is indisputably a bug in (some versions of) NetBSD. If I
> can seek past the end of file, read() shouldn't consider it a hard error
> to read there --- and in any case, EFAULT isn't a very reasonable error
> code to return. Since it seems not to be a widespread problem, I
Tom Ivar Helbekkmo <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
> CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
> + ERROR: cannot read block 3 of hash_i4_index: Bad address
>>
>> "Bad address"? That seems pretty bizarre.
> This is obviously some
matthew green <[EMAIL PROTECTED]> writes:
> i also believe the `Bad address' errors were caused when the test
> was run in an NFS mounted directory.
You may have something, there. My test run on the VAX was over NFS.
I set up NetBSD on a VAX specifically to test PostgreSQL 7.1, but I
didn't hav
> >> CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
> >> + ERROR: cannot read block 3 of hash_i4_index: Bad address
>
> "Bad address"? That seems pretty bizarre.
This is obviously something that shows up on _some_ NetBSD platforms.
The above w
matthew green <[EMAIL PROTECTED]> writes:
> digging into the regression.diffs, i can see that:
> - reltime failed because it just had:
> ! psql: Backend startup failed
>The postmaster log file should have more info, but a first thought is
>that you ran up against
>> digging into the regression.diffs, i can see that:
>> - reltime failed because it just had:
>> ! psql: Backend startup failed
The postmaster log file should have more info, but a first thought is
that you ran up against process or swap-space limitations. The parallel
>> i will be reinstalling this SS20 with a full installation sometime in
>> the next few days. i will re-run the testsuite after this to see if
>> that is causing any of the lossage.
Please let us know.
actually, i had a classic i could test with -- all except horology passe
> after running `unlimit' (tcsh) before `make check', the only failures i have
> are the horology (expected) and the inherit sorted failures, on NetBSD/sparc64.
I'll mark both NetBSD/sparc as supported, for both 32 and 64-bit builds.
Thanks!
- Thomas
Tom Ivar Helbekkmo <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
> CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
> + ERROR: cannot read block 3 of hash_i4_index: Bad address
>>
>> "Bad address"? That seems pretty bizarre.
> This is obviously some
matthew green <[EMAIL PROTECTED]> writes:
> digging into the regression.diffs, i can see that:
> - reltime failed because it just had:
> ! psql: Backend startup failed
>The postmaster log file should have more info, but a first thought is
>that you ran up against process or swap-space
Tom Lane <[EMAIL PROTECTED]> writes:
> >> CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
> >> + ERROR: cannot read block 3 of hash_i4_index: Bad address
>
> "Bad address"? That seems pretty bizarre.
This is obviously something that shows up on _some_ NetBSD platforms
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Anyone have suggestions for Mathew?
>> for postgresql-7.1RC2.tar.gz, here is my `make check' for NetBSD/sparc64:
>> digging into the regression.diffs, i can see that:
>> - reltime failed because it just had:
>> ! psql: Backend startup failed
The pos
(cc'd the -hackers mailing list)
Thanks for the reports Matthew. There is a single failure in the
NetBSD/sparc64 test due to a problem in the reltime test (or in starting
the reltime test). There is a different failure in your NetBSD/sparc
test, but since you are not confident about your installa
> Unreported or problem platforms:
>
> Linux 2.0.x MIPS 7.0 2000-04-13 (Tatsuo has lost machine)
> mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii
> NetBSD m68k7.0 2000-04-10 (Henry has lost machine)
> NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo
> QNX 4.25 x86 7.0 2000-04-
I just built and tested RC1 on Linux 2.4.2, with glibc-2.2.2 and
gcc-2.95.2 on a Debian 2.2+ x86 system. ("+" implying some packages
from "unstable".)
I configured it --with-perl --with-openssl --with-CXX.
It built without errors, but with a few warnings.
This one seemed (portably) odd:
--
> I still don't see an entry for Linux 2.4.x
My (uncommitted) updates to the real list show 2.4.2 in the comments
section. I may remove all mention of versions, since it seems that most
released versions of x86 Linux run PostgreSQL successfully.
Comments?
- Thomas
> > Un
On Sat, Mar 31, 2001 at 12:02:35PM +1200, Franck Martin allegedly wrote:
> I still don't see an entry for Linux 2.4.x
>
> Cheers.
This should fix that:
==
All 76 tests passed.
==
rm regress.o
make[2]: Leaving directory `/usr/exp/tmp/postgresql-7.1RC1/sr
I still don't see an entry for Linux 2.4.x
Cheers.
Thomas Lockhart wrote:
> Unreported or problem platforms:
>
> Linux 2.0.x MIPS 7.0 2000-04-13 (Tatsuo has lost machine)
> mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii
> NetBSD m68k7.0 2000-04-10 (Henry has lost machine)
> NetBSD Sp
On Fri, 30 Mar 2001, Mathijs Brands wrote:
> On Fri, Mar 30, 2001 at 03:17:06PM +, Thomas Lockhart allegedly wrote:
> > And here are the up-to-date platforms; thanks for the reports:
>
>
>
> > Solaris 2.7 Sparc 7.1 2001-03-22, Marc Fournier
>
> Marc, was this done without unix sockets?
nop
On Fri, Mar 30, 2001 at 03:17:06PM +, Thomas Lockhart allegedly wrote:
> And here are the up-to-date platforms; thanks for the reports:
> Solaris 2.7 Sparc 7.1 2001-03-22, Marc Fournier
Marc, was this done without unix sockets?
Mathijs
--
It's not that perl programmers are idiots, it's
Unreported or problem platforms:
Linux 2.0.x MIPS 7.0 2000-04-13 (Tatsuo has lost machine)
mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii
NetBSD m68k7.0 2000-04-10 (Henry has lost machine)
NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo
QNX 4.25 x86 7.0 2000-04-01, Dr. Andrea
24 matches
Mail list logo
