Re: [HACKERS] Linux Largefile Support In Postgresql RPMS - Mailing list pgsql-general

From Helge Bahmann
Subject Re: [HACKERS] Linux Largefile Support In Postgresql RPMS
Date
Msg-id Pine.LNX.4.44.0208131701400.10566-100000@lothlorien.stunet.tu-freiberg.de
Whole thread Raw
In response to Re: [HACKERS] Linux Largefile Support In Postgresql RPMS  (Tommi Maekitalo <t.maekitalo@epgmbh.de>)
Responses Re: [HACKERS] Linux Largefile Support In Postgresql RPMS  (Andrew Sullivan <andrew@libertyrms.info>)
Re: [HACKERS] Linux Largefile Support In Postgresql RPMS  (strange@nsk.yi.org)
List pgsql-general
If all the 2GB problem is only about pg_dump may I suggest a work-around?

  pg_dump | cat >dumpfile.sql

works without problems if "cat" is largefile-enabled; this puts the burden
of supplying largefile-enabled binaries on the operating system
distributor; similiar constructions work for all other postgres tools

Apart from this I think it is perfectly safe to enable largefile
compilation on linux unconditionally; the only major linux filesystem (I'm
discounting VFAT and the like here) that cannot handle files >2GB is NFSv2
(but NFSv3 works), the error code and signal you get from writing a too
large file (EFBIG "File too large" and SIGXFSZ "File size limit exceeded")
should give the administrator prominent hints what might be wrong

Note that in Debian Woody all system binaries (cp, cat etc.) are compiled
with largefile support enabled, I think this applies to all other
distributions as well

Regards
--
Helge Bahmann <bahmann@math.tu-freiberg.de>             /| \__
The past: Smart users in front of dumb terminals       /_|____\
                                                     _/\ |   __)
$ ./configure                                        \\ \|__/__|
checking whether build environment is sane... yes     \\/___/ |
checking for AIX... no (we already did this)            |


pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: oid2name reports much fewer files...
Next
From: Mario Weilguni
Date:
Subject: Re: oid2name reports much fewer files...