Re: big tables with lots-o-rows

Поиск
Список
Период
Сортировка
От Sam Barnett-Cormack
Тема Re: big tables with lots-o-rows
Дата
Msg-id Pine.LNX.4.50.0307011526160.3744-100000@short.lancs.ac.uk
обсуждение исходный текст
Ответ на Re: big tables with lots-o-rows  (Michiel Lange <michiel@minas.demon.nl>)
Список 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 по дате отправления:

Предыдущее
От: "Daniel Seichter"
Дата:
Сообщение: Re: postgreSQL users = LDAP users?
Следующее
От: Jonathan Gardner
Дата:
Сообщение: Re: replication/redundancy