Re: Restricting schema sizes - Mailing list pgsql-admin

From Kieren Scott
Subject Re: Restricting schema sizes
Date
Msg-id BAY149-w576121FBC100CCF74D469CAE5C0@phx.gbl
Whole thread Raw
In response to Re: Restricting schema sizes  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-admin
Many thanks.
Is it possbile to set statement_timeout at the user-level in 8.2? e.g. by "alter role myuser set statement_timeout=123456;"
Where can I find out what level statement_timeout can be set at e.g. session, user, database..?

Kieren


Date: Sun, 17 Oct 2010 15:45:16 -0400
From: greg@2ndquadrant.com
To: kierenscott@hotmail.com
CC: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Restricting schema sizes

Kieren Scott wrote:
.ExternalClass .ecxhmmessage P {padding:0px;} .ExternalClass body.ecxhmmessage {font-size:10pt;font-family:Tahoma;} 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

pgsql-admin by date:

Previous
From: Robert Treat
Date:
Subject: Re: WAL log shipping + Streaming replication PG 9.0 questions
Next
From: Ken Lalonde
Date:
Subject: DROP ROLE: how to detect active sessions?