Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id 727DD133729E
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Sun, 17 Oct 2010 16:45:29 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 37817-06 for
	<pgsql-admin-postgresql.org@mail.postgresql.org>;
	Sun, 17 Oct 2010 19:45:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from moutng.kundenserver.de (moutng.kundenserver.de
	[212.227.126.171])
	by mail.postgresql.org (Postfix) with ESMTP id 689FE1336DB6
	for <pgsql-admin@postgresql.org>; Sun, 17 Oct 2010 16:45:21 -0300 (ADT)
Received: from [192.168.1.6] (static-71-179-240-8.bltmmd.fios.verizon.net
	[71.179.240.8])
	by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis)
	id 0MKbX5-1P7qPq3ctr-001ttW; Sun, 17 Oct 2010 21:45:18 +0200
Message-ID: <4CBB524C.4030801@2ndquadrant.com>
Date: Sun, 17 Oct 2010 15:45:16 -0400
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Kieren Scott <kierenscott@hotmail.com>
CC: pgsql-admin@postgresql.org
Subject: Re: Restricting schema sizes
References: <BAY149-w53D2CD9EDFAFED3996BF3EAE590@phx.gbl>
In-Reply-To: <BAY149-w53D2CD9EDFAFED3996BF3EAE590@phx.gbl>
Content-Type: multipart/alternative;
	boundary="------------070504060804030806050202"
X-Provags-ID: V02:K0:jkjjMEde05ImvYkdt/tzLGRMWCJ8FJDGqkGmJN6WdFq
	mElQBrZMTjOnPBbJFDDexK5uj3CulZULOUBQe5R6RqZP0XouES
	ZYJ/KedjeQlRgVrWFD+zMv0RWI7i1/dvqNSELjoP82mZUack73
	hkk8haqcSmIsrJFyhJ9t4XkOwVVNuC1mq/0zqjPlcodLieL3IU
	fTgWN9DkZJiDr0R9jsDoSjR0yzB/Kjvq/+NcFKjN5I=
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.899 tagged_above=-10 required=5
	tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001
X-Spam-Level: 
X-Archive-Number: 201010/143
X-Sequence-Number: 35884

This is a multi-part message in MIME format.
--------------070504060804030806050202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kieren Scott wrote:
> What is the best way to restrict/limit the size that a schema can grow 
> too in Postgresql?
> ...
> The other option I can think of is writing a script that monitors the 
> size of the objects
> within a schema. The danger here is that a user could potentially 
> create a huge table
> as a result of a bad query (cartesian join etc) and fill the 
> application tablespace / filesystem.

You have answered your own question here.  There isn't any facility in 
PostgreSQL yet to enforce disk space usage, so if this requirement is a 
must it's something you'll have to build yourself.  The 
tablespace->filesystem mapping you suggested is probably a good idea to 
house these things at, to prevent one user from taking out the main part 
of the database with something they do.

One way that you can try to limit the damage of rogue queries on top of 
that is to set statement_timeout so they just get cancelled if they run 
for too long.  If the tables are being populated by a single statement 
and you set that to a moderate amount of time, that should be effective 
at cutting off any of the really bad ones after they've run for a 
while.  You'll have to experiment at just how long that timeout should 
be.  If you set log_min_duration_statement (which is a general good idea 
in this situation anyway) and look at what kind of runtime common 
intense but not crippling queries take, that's one way to get feedback 
on where the timeout should be.

-- 
Greg Smith, 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support  www.2ndQuadrant.us
Author, "PostgreSQL 9.0 High Performance"    Pre-ordering at:
https://www.packtpub.com/postgresql-9-0-high-performance/book


--------------070504060804030806050202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Kieren Scott wrote:
<blockquote cite="mid:BAY149-w53D2CD9EDFAFED3996BF3EAE590@phx.gbl"
 type="cite">
  <style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>What
is the best way to restrict/limit the size that a schema can grow too
in Postgresql?<br>
...<br>
The other option I can think of is writing a script that monitors the
size of the objects <br>
within a schema. The danger here is that a user could potentially
create a huge table <br>
as a result of a bad query (cartesian join etc) and fill the
application tablespace / filesystem.<br>
</blockquote>
<br>
You have answered your own question here.&nbsp; There isn't any facility in
PostgreSQL yet to enforce disk space usage, so if this requirement is a
must it's something you'll have to build yourself.&nbsp; The
tablespace-&gt;filesystem mapping you suggested is probably a good idea
to house these things at, to prevent one user from taking out the main
part of the database with something they do.<br>
<br>
One way that you can try to limit the damage of rogue queries on top of
that is to set statement_timeout so they just get cancelled if they run
for too long.&nbsp; If the tables are being populated by a single statement
and you set that to a moderate amount of time, that should be effective
at cutting off any of the really bad ones after they've run for a
while.&nbsp; You'll have to experiment at just how long that timeout should
be.&nbsp; If you set log_min_duration_statement (which is a general good
idea in this situation anyway) and look at what kind of runtime common
intense but not crippling queries take, that's one way to get feedback
on where the timeout should be.<br>
<br>
<pre class="moz-signature" cols="72">-- 
Greg Smith, 2ndQuadrant US <a class="moz-txt-link-abbreviated" href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a> Baltimore, MD
PostgreSQL Training, Services and Support  <a class="moz-txt-link-abbreviated" href="http://www.2ndQuadrant.us">www.2ndQuadrant.us</a>
Author, "PostgreSQL 9.0 High Performance"    Pre-ordering at:
<a class="moz-txt-link-freetext" href="https://www.packtpub.com/postgresql-9-0-high-performance/book">https://www.packtpub.com/postgresql-9-0-high-performance/book</a>
</pre>
</body>
</html>

--------------070504060804030806050202--