From: | teunis <teunis(at)mauve(dot)computersupportcentre(dot)com> |
---|---|
To: | hackers(at)postgreSQL(dot)org |
Subject: | a small problem with current CVS - wondering how to debug |
Date: | 1998-01-15 19:54:13 |
Message-ID: | Pine.LNX.3.96.980115123753.7294A-100000@sigil.computersupportcentre.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I keep getting:
Too Large Allocation Request("!(0 < (size) && (size) <=
(0xfffffff)):size=-3 [0xfffffffd]", File: "mcxt.c", Line: 232)
!(0 < (size) && (size) <= (0xfffffff)) (0) [No such file or directory]
from a simple select:
SELECT * from provinces;
incidentally, "SELECT oid from provinces;" works...
(as does any select on one component)... but checking...
Nope - countrycode fails. Prints out garbage (8bit garbage at that)
As do all fields after that - though they're just bad data.
For comparison, I have another database with "varchar(50), integer,
timestamp, timestamp" - and the only noncorrupted field is the first
varchar() entry. Perhaps it's in the string-handling?
The contents of the database:
---
CREATE TABLE provinces
(
code char(4), -- ...
name varchar(50), -- ...
countrycode char(2), -- ...
country varchar(50), -- ...
-- creation and modification dates of this record...
creationdate timestamp default now(),
modifydate timestamp default now()
);
INSERT INTO provinces (code, name, countrycode, country)
VALUES ('bc','British Columbia','ca','Canada');
INSERT INTO provinces (code, name, countrycode, country)
VALUES ('ab','Alberta', 'ca','Canada');
INSERT INTO provinces (code, name, countrycode, country)
VALUES ('alta','Alberta', 'ca','Canada');
-- one gets tired of databases referring to "state"... so time to turn the
-- tables *grin*
INSERT INTO provinces (code, name, countrycode, country)
VALUES ('wa', 'Washington', 'us','United States');
---
Incidentally, this worked perfectly up 'till christmas-CVS. I had some
other problems so I upgraded... and now it core-dumps 'psql' and sends
this to the backend.
On debugging psql I found the error in "UP()", but as I don't know how to
use gdb properly I can't look any deeper (I've always preferred logfiles -
especially when working on videodriver code :)
[mayhaps psql needs better recovery code... will have to look at that
sometime]
JDBC also fails FWIW - with these messages: (same query)
java.sql.SQLException: Error reading from backend: java.io.IOException: EOF
at postgresql.PG_Stream.ReceiveInteger(PG_Stream.java:184)
at postgresql.PG_Stream.ReceiveTuple(PG_Stream.java:256)
at postgresql.Connection.ExecSQL(Connection.java:626)
at postgresql.Statement.execute(Statement.java:259)
at postgresql.Statement.executeQuery(Statement.java:46)
at Mauve.Main.readProvinces(Main.java:234)
at Mauve.Main.main(Main.java:363)
java.sql.SQLException: I/O Error: java.io.IOException: Broken pipe
at postgresql.Connection.ExecSQL(Connection.java:583)
at postgresql.Statement.execute(Statement.java:259)
at postgresql.Statement.executeQuery(Statement.java:46)
at Mauve.Main.readPaymentForms(Main.java:252)
at Mauve.Main.main(Main.java:366)
I suspect a bug somewhere - but don't know how to find it. Or if my
data's incorrect.... many things have changed in postgres.
Platform:
linux 2.0.33 (got tired of being flamed for using 2.1 kernels)
glibc-2.0.5c (standard! ref: redhat-5.0)
gcc 2.7.2.1 (I also have egc-1.0 but I don't trust it yet)
Cyrix 6x86, 40M ram, ~5G drivespace
Though it's nice to finally see large objects working *grin*.
G'day, eh? :)
- Teunis
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 1998-01-15 20:27:21 | Re: New pg_pwd patch and stuff |
Previous Message | The Hermit Hacker | 1998-01-15 19:44:20 | *Major* Patch for PL |