On Tue, Aug 13, 2002 at 05:19:31PM +0200, Helge Bahmann wrote:
> If all the 2GB problem is only about pg_dump may I suggest a work-around?
>
> pg_dump | cat >dumpfile.sql
The only reason to care for large file support is if pg_dump will be
seeking and telling on files it creates, not postgresql's data files, as
those will be split up by postgresql at the 1 Gb boundary.
I very much doubt pg_dump would be seeking or telling on stdout, as it may
be a pipe, a tty, a socket, etc., so you can skip the cat and just do
pg_dump > dumpfile.sql.
Oh, and cat doesn't need to be largefile-enabled as it never seeks in
files, as neither does pg_dump, as it doesn't, or shouldn't (I see no need
for), seek in the output file.
I really see no point in this discussion. Will the backend ever seek or
tell any file it uses? Its data files will be smaller than 1 Gb, so no
problem there. The only worry would be the COPY, but that doesn't need
those two functions, does it?
Same for any frontend tool. Does it need the seek and tell? I'll rather
have then eliminated when not really needed, than having to worry about
filesystem and OS support.
The only thing to worry would be when opening the large files, but a
simple rule in autoconf will set the needed #define in the headers...
Regards,
Luciano Roha
> --
> 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) |
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
--
Consciousness: that annoying time between naps.