From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | dave(dot)bath(at)unix(dot)net, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Pre-allocation of space: a business rationale |
Date: | 2005-11-03 19:21:30 |
Message-ID: | 20051103192130.GT55520@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Wed, Nov 02, 2005 at 10:48:00PM -0500, Tom Lane wrote:
> "Bath, David" <dave(dot)bath(at)unix(dot)net> writes:
> > C) I want to avoid the possibility of uncontrolled growth of luser data
> > blowing disk leading to stoppage of 24x7 data.
>
> You put the luser data and the critical data into separate tablespaces
> that are in separate partitions (filesystems). End of problem ...
>
> (And no, I don't believe in having Postgres reinvent filesystem-level
> functionality. If you didn't set up appropriate hard partitions,
> consider a loopback filesystem for your tablespace.)
Does every OS we support have a loopback filesystem? Can they all impose
space limits?
It doesn't seem unreasonable to support a limit on tablespace (or table)
size. It also doesn't seem like it would take that much code to add
support for it. Of course usual disclaimer about 'submit a patch then'
applies, but it sounds like such a patch would get rejected out-of-hand.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-11-03 19:31:19 | Re: pg_dump and truncate |
Previous Message | Randall Smith | 2005-11-03 18:43:47 | Backup/Restore Views |