Re: PostgreSQL pre-7.1 Linux/Alpha Status... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PostgreSQL pre-7.1 Linux/Alpha Status...
Date
Msg-id 5546.977330473@sss.pgh.pa.us
Whole thread Raw
In response to PostgreSQL pre-7.1 Linux/Alpha Status...  (Ryan Kirkpatrick <pgsql@rkirkpat.net>)
Responses Re: PostgreSQL pre-7.1 Linux/Alpha Status...  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: PostgreSQL pre-7.1 Linux/Alpha Status...  (Ryan Kirkpatrick <rkirkpat@rkirkpat.net>)
Re: PostgreSQL pre-7.1 Linux/Alpha Status...  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Ryan Kirkpatrick <pgsql@rkirkpat.net> writes:
> INSERT INTO OID_TBL(f1) VALUES ('-1040');
> ERROR:  oidin: error reading "-1040": value too large

That's coming from a possibly-misguided error check that I put into
oidin():
unsigned long cvt;char       *endptr;
cvt = strtoul(s, &endptr, 10);
...
/* * Cope with possibility that unsigned long is wider than Oid. */result = (Oid) cvt;if ((unsigned long) result !=
cvt)   elog(ERROR, "oidin: error reading \"%s\": value too large", s);
 

On a 32-bit machine, -1040 converts to 4294966256, but on a 64-bit
machine it converts to 2^64-1040, and the test is accordingly deciding
that that value won't fit in an Oid.

Not sure what to do about this.  If you had actually typed 2^64-1040,
it would be appropriate for the code to reject it.  But I hadn't
realized that the extra check would introduce a discrepancy between
32- and 64-bit machines for negative inputs.  Maybe it'd be better just
to delete the check.  Comments anyone?

> SELECT p.name, p.hobbies.name FROM person* p;
> pqReadData() -- backend closed the channel unexpectedly.

Backtrace please?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: RE: SSL Connections
Next
From: "Magnus Naeslund\(f\)"
Date:
Subject: Re: PostgreSQL pre-7.1 Linux/Alpha Status...