I've gotten a fairly recent snapshot from FTP and compiled it
up on Alpha/linux.
On running, the forked process dies with a palloc error....it
was trying to grab 4 gig worth of memory.
I've tracked this problem down to
backend/utils/cache/relcache.c
in function init_irels:
len is defined as Size, which I've checked out and it turns
out to be size_t...which happens to be 8 byte on an alpha.
len is uninitialised.
further down in init_irels
if ((nread = FileRead(fd, (char *) &len, sizeof(int))) != sizeof(int))
which should set len to be the size of the relation read from disk.
What is happening is that 4 bytes are being read from the file
and saved in len. Writing 4 into 8 doesn't work too well so a
complete mess is made.
Initialising len to 0 fixes the problem, but I'm thinking that this
isn't the best solution. Since len is size_t, I'm figuring that the
big scheme of things is to allow for larger tables on 64 bit machines.
I'm new to the internals so I don't know if the DB files are architecture
independant (still wading through documentation)....if it isn't...then I
guess Size should be replaced with int...and all should be happy.
What is the correct way about fixing this?
My ultimate goal here is to get timestamps working correctly on the alpha.
You probably already know...but incase you didn't...
create table dat ( d date, t timestamp);
CREATE
insert into dat values ('1999-01-22', '1999-01-22 16:00:00');
INSERT 18602 1
select * from dat; d|t
----------+----------------------
01-22-1999|2135-02-28 22:28:16+00
(1 row)
Sometimes...the select the first time returns the correct values...
but on doing the select again immidately after the first select
will return 2135 again (probably due to the caching).
Any help on where I should be looking would be greatly received!
Cheers!
--
Adrian Gartland - Server Development Manager
Oregan Networks UK Ltd Tel: +44 (0) 1530 56 33 11
Huntingdon Court, Ashby de la Zouch Fax: +44 (0) 1530 56 33 22
Leicestershire, LE65 1AH, United Kingdom WWW: http://www.oregan.net/
