status of 64bit ints? was: Re: Transaction ID wraparound: problem and proposed solution

From: Marko Kreen <marko(at)l-t(dot)ee>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: status of 64bit ints? was: Re: Transaction ID wraparound: problem and proposed solution
Date: 2001-01-20 15:53:37
Message-ID: 20010120175337.B10475@l-t.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > The first thought that comes to mind is that XIDs should be promoted to
> > eight bytes. However there are several practical problems with this:
> > * portability --- I don't believe long long int exists on all the
> > platforms we support.

> > regards, tom lane

How long will such platforms be supported? When will 64bit be a
requirement?

The c.h has following lines in case there is not 64 bit ints:

/* Won't actually work, but fall back to long int so that code
* compiles */
typedef long int int64;
typedef unsigned long int uint64;
#define INT64_IS_BUSTED

At the memont the int64 is mostly used in 'int8' case, so its
not too bad. But probably there will be more cases where int64
is useful, so PostgreSQL will start misbehaving on those
platforms, which is worse than not supporting them officially.

Or should int64 be avoided at any cost?

--
marko

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2001-01-20 15:56:12 Re: AW: AW: AW: Re: tinterval - operator problems on AIX
Previous Message Marko Kreen 2001-01-20 15:31:28 Re: binary operators on integers