Re: big tables with lots-o-rows - Mailing list pgsql-admin

From Sam Barnett-Cormack
Subject Re: big tables with lots-o-rows
Date
Msg-id Pine.LNX.4.50.0307011526160.3744-100000@short.lancs.ac.uk
Whole thread Raw
In response to Re: big tables with lots-o-rows  (Michiel Lange <michiel@minas.demon.nl>)
List pgsql-admin
On Tue, 1 Jul 2003, Tom Lane wrote:

> Sam Barnett-Cormack <s.barnett-cormack@lancaster.ac.uk> writes:
> > On Tue, 1 Jul 2003, Michiel Lange wrote:
> >> _Could_ it be that you're hitting a filesystem limit here? I am not 100%
> >> certain, but I believe ext2 by default supports only files of 2.? GB at
> >> most... Yet I am not certain if this is really what's wrong, but I would
> >> look in that direction.
>
> > IT's a kernel-level limit, for single files. A kernel recompile with
> > large file support will eliminate that, if it is the problem.
>
> None of that has the slightest relevance to Postgres, however, since we
> always split large tables into gigabyte-sized segment files.  (The only
> reason there's a largefile compilation option is so you can work with
> greater-than-2GB dump scripts in pg_dump and pg_restore; the backend
> does not need it.)

I was under the impression that largefile would make the DB store data
in larger files, where appropriate, so using largefile when your kernel
does not support large files could create such an error

> My guess is that the OP ran into an actual out-of-space situation,
> or possibly a disk quota or ulimit limitation that was reported as
> out-of-space.

For example, running out of inodes is also reported as out-of-space. Is
anything else on the same partition?

--

Sam Barnett-Cormack
Software Developer                           |  Student of Physics & Maths
UK Mirror Service (http://www.mirror.ac.uk)  |  Lancaster University

pgsql-admin by date:

Previous
From: "Daniel Seichter"
Date:
Subject: Re: postgreSQL users = LDAP users?
Next
From: Jonathan Gardner
Date:
Subject: Re: replication/redundancy