From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Oliver Elphick <olly(at)lfix(dot)co(dot)uk> |
Cc: | Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] Linux Largefile Support In Postgresql RPMS |
Date: | 2002-08-12 20:07:18 |
Message-ID: | Pine.LNX.4.44.0208122045270.10067-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Oliver Elphick writes:
> One person said:
> However compiling with largefile support will change the size
> of off_t from 32 bits to 64 bits - if postgres uses off_t or
> anything else related to file offsets in a binary struct in one
> of the database files you will break stuff pretty heavily. I
> would not compile postgres with largefile support until it
> is officially supported by the postgres developers.
>
> but I cannot see that off_t is used in such a way.
This is not the only issue. You really need to check all uses of off_t
(for example printf("%ld", off_t) will crash) and all places where off_t
should have been used in the first place. Furthermore you might need to
replace ftell() and fseek() by ftello() and fseeko(), especially if you
want pg_dump to support large archives.
Still, most of the configuration work is already done in Autoconf (see
AC_FUNC_FSEEKO and AC_SYS_LARGEFILE), so the work might be significantly
less than the time spent debating the merits of large files on these
lists. ;-)
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Bolden, Thomas | 2002-08-12 20:29:26 | trigger column update |
Previous Message | Hubert depesz Lubaczewski | 2002-08-12 18:24:50 | when to use index, and when not to us index - *the* answer :) |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2002-08-12 20:50:56 | CLUSTER all tables at once? |
Previous Message | Jeroen T. Vermeulen | 2002-08-12 19:59:37 | Re: libpqxx |