From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sam Barnett-Cormack <s(dot)barnett-cormack(at)lancaster(dot)ac(dot)uk> |
Cc: | Michiel Lange <michiel(at)minas(dot)demon(dot)nl>, "Chris G(dot) Nicholas" <cgn(at)globexplorer(dot)com>, "" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: big tables with lots-o-rows |
Date: | 2003-07-01 14:11:24 |
Message-ID: | 2816.1057068684@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Sam Barnett-Cormack <s(dot)barnett-cormack(at)lancaster(dot)ac(dot)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.)
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Sam Barnett-Cormack | 2003-07-01 14:27:27 | Re: big tables with lots-o-rows |
Previous Message | scott.marlowe | 2003-07-01 13:24:30 | Re: Max file size |