Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL pre-7.1 Linux/Alpha Status...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ryan Kirkpatrick <pgsql(at)rkirkpat(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-ports(at)postgresql(dot)org
Subject: Re: PostgreSQL pre-7.1 Linux/Alpha Status...
Date: 2000-12-20 16:41:13
Message-ID: 5546.977330473@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-ports
Ryan Kirkpatrick <pgsql(at)rkirkpat(dot)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

In response to

Responses

pgsql-ports by date

Next:From: Magnus Naeslund(f)Date: 2000-12-20 16:58:27
Subject: Re: PostgreSQL pre-7.1 Linux/Alpha Status...
Previous:From: Ryan KirkpatrickDate: 2000-12-20 04:08:00
Subject: PostgreSQL pre-7.1 Linux/Alpha Status...

pgsql-hackers by date

Next:From: Paul A VixieDate: 2000-12-20 16:53:09
Subject: day 2 results
Previous:From: Magnus HaganderDate: 2000-12-20 16:26:01
Subject: RE: SSL Connections

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group