Received: from localhost.localdomain (postgresql.org [64.49.215.8])
	by localhost (Postfix) with ESMTP id ED2B4476A15
	for <pgsql-sql@postgresql.org>; Wed, 26 Jun 2002 20:35:54 -0400 (EDT)
Mailbox-Line: From tswan@idigx.com  Wed Jun 26 20:35:54 2002
Received: from stubee.d2hosting.net (d2hosting.net [66.70.41.160])
	by postgresql.org (Postfix) with ESMTP id E77E4476695
	for <pgsql-sql@postgresql.org>; Wed, 26 Jun 2002 19:41:49 -0400 (EDT)
Received: from firewall.oxford.d2interactive.com
	(firewall.oxford.d2interactive.com [68.16.167.2])
	by stubee.d2hosting.net (8.11.6/linuxconf) with ESMTP id g5QNfpB15339;
	Wed, 26 Jun 2002 18:41:52 -0500
Received: from idigx.com (host128.oxford.d2interactive.com [192.168.0.128])
	by firewall.oxford.d2interactive.com (8.11.6/linuxconf) with ESMTP id
	g5QNfoS16601; Wed, 26 Jun 2002 18:41:51 -0500
Message-ID: <3D1A513D.30805@idigx.com>
Date: Wed, 26 Jun 2002 18:41:49 -0500
From: Thomas Swan <tswan@idigx.com>
Reply-To: tswan@idigx.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.0.0) Gecko/20020625
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: josh@agliodbs.com
Cc: Eric <emayo@pozicom.net>, pgsql-sql@postgresql.org
Subject: Re: Limiting database size
References: <200206071442.36850.josh@agliodbs.com> <afahdp$n9p$1@news.hub.org>
	<200206261112.02982.josh@agliodbs.com>
Content-Type: multipart/alternative;
	boundary="------------050908030807040003020003"
X-Spam-Status: No, hits=1.8 required=5.0
	tests=NO_MX_FOR_FROM
	version=2.30
X-Spam-Level: *
X-Archive-Number: 200206/358
X-Sequence-Number: 8323

--------------050908030807040003020003
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Josh Berkus wrote:

>Eric,
>
>>I like the idea of putting it on a hard disk or partition of fixed size and
>>waiting for the DB to simply crash.
>>hahaha
>>    
>>
>Yeah.  <grin>   It's what MS SQL Server does, though.   As I said, I think the 
>whole concept of limiting database size in MB is fundamentally flawed.   I 
>mean, what's the database supposed to do when it runs out of space?
>
Refuse updates, deletes, and inserts (from anything other than a DB 
superuser).  However you should be able to select data.  Once the 
database has exceeded its bounds, it would revert to read only status 
and wait for administrative intervention such as enlarging the quota 
(allocatable size) or altering the database to reduce its size.

Adding the checks wouldn't break existing databases if you defaulted the 
checks to off.

This could also significantly help in hosting situations by preventing a 
client for exceeding a specified quota and taking over the allocated 
area for the postgres database.

Thinking about it, it seems like a good safety feature (aside from good 
partitioning and system layout to begin with).





--------------050908030807040003020003
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Josh Berkus wrote:<br>
<blockquote type="cite" cite="mid200206261112.02982.josh@agliodbs.com">
  <pre wrap="">Eric,</pre>
  <blockquote type="cite">
    <pre wrap="">I like the idea of putting it on a hard disk or partition of fixed size and
waiting for the DB to simply crash.
hahaha
    </pre>
  </blockquote>
  <pre wrap=""><!---->Yeah.  &lt;grin&gt;   It's what MS SQL Server does, though.   As I said, I think the 
whole concept of limiting database size in MB is fundamentally flawed.   I 
mean, what's the database supposed to do when it runs out of space?</pre>
</blockquote>
Refuse updates, deletes, and inserts (from anything other than a DB superuser).
&nbsp;However you should be able to select data. &nbsp;Once the database has exceeded
its bounds, it would revert to read only status and wait for administrative
intervention such as enlarging the quota (allocatable size) or altering the
database to reduce its size.<br>
<br>
Adding the checks wouldn't break existing databases if you defaulted the
checks to off.<br>
<br>
This could also significantly help in hosting situations by preventing a
client for exceeding a specified quota and taking over the allocated area
for the postgres database.<br>
<br>
Thinking about it, it seems like a good safety feature (aside from good partitioning
and system layout to begin with).<br>
<br>
<br>
<br>
<br>
</body>
</html>

--------------050908030807040003020003--