Re: pg_upgrade

It looks like it's related to atol

$ cat test-atol.c
#include <stdlib.h>
#include <stdio.h>

int
main(int argc, char **argv)
{
unsigned int test1;
long test2;
long long test3;
unsigned int test4;

test1 = (unsigned int)atol("3000767169");
test2 = (long)atol("3000767169");
test3 = atoll("3000767169");
test4 = (unsigned int)atoll("3000767169");

fprintf(stderr,"%u %ld %lld %u\n",test1,test2,test3,test4);
}

$ make test-atol
cc test-atol.c -o test-atol
$ ./test-atol
2147483647 2147483647 3000767169 3000767169

I think C90 and C99 specify different behaviors with atol

Is there some standard way postgresql parses integer strings? Maybe that method should be used instead of duplicating the functionality so at least the two behave consistently.

--brian

On Sep 28, 2010, at 2:00 PM, Bruce Momjian wrote:

> Brian Hirt wrote:
>> Looks like pg_upgrade is using 32bit oids. 2147483647 is the max signed 32 bit int, but the oids for my tables are clearly larger than that.
>>
>> == output from pg_upgrade ==
>> Database: basement84_dev
>> relname: mit.company: reloid: 2147483647 reltblspace:
>> relname: mit.company_history: reloid: 2147483647 reltblspace:
>>
>> == output from catalog query ==
>> basement84_dev=# select c.oid,c.relname from pg_catalog.pg_namespace n, pg_catalog.pg_class c where n.oid = c.relnamespace and n.nspname = 'mit';
>> oid | relname
>> ------------+--------------------
>> 3000767630 | company
>> 3000767633 | company_history
>> (22 rows)
>>
>
> Interesting. Odd it would report the max 32-bit signed int. I wonder
> if it somehow is getting set to -1. I looked briefly at the pg_upgrade
> code and it appears to put all oids in unsigned ints.
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general