pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedRestricting schema sizes
4+ messages / 3 participants
[nested] [flat]
* Restricting schema sizes
@ 2010-10-17 11:02 Kieren Scott <kierenscott@hotmail.com>
0 siblings, 2 replies; 4+ messages in thread
From: Kieren Scott @ 2010-10-17 11:02 UTC (permalink / raw)
To: pgsql-admin
Hi,
What is the best way to restrict/limit the size that a schema can grow too in Postgresql?
If I want to have a scratchpad area within my database to allow users to create tables,
how can I control the size of the objects they can create?
Would I have to create a dedicated filesystem and then create a tablespace on that
filesystem. Users could then create objects in that tablespace until they fill the filesystem.
Is there a setting in Postgresql whereby I can allocate a quota of space within a
tablespace for each schema?
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.
Many thanks.
=
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Restricting schema sizes
@ 2010-10-17 19:36 Scott Marlowe <scott.marlowe@gmail.com>
parent: Kieren Scott <kierenscott@hotmail.com>
1 sibling, 0 replies; 4+ messages in thread
From: Scott Marlowe @ 2010-10-17 19:36 UTC (permalink / raw)
To: Kieren Scott <kierenscott@hotmail.com>; +Cc: pgsql-admin
On Sun, Oct 17, 2010 at 5:02 AM, Kieren Scott <kierenscott@hotmail.com> wrote:
> Hi,
>
> What is the best way to restrict/limit the size that a schema can grow too
> in Postgresql?
>
> If I want to have a scratchpad area within my database to allow users to
> create tables,
> how can I control the size of the objects they can create?
>
> Would I have to create a dedicated filesystem and then create a tablespace
> on that
> filesystem. Users could then create objects in that tablespace until they
> fill the filesystem.
Yes.
> Is there a setting in Postgresql whereby I can allocate a quota of space
> within a
> tablespace for each schema?
Currently, no. I don't know if someone is working on that type of thing or not.
> 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.
Yeah, you'd always be checking after the fact. I guess it depends on
your needs. It might be good enough to keep track of usage and warn
users when they go over if you've got storage to spare, and just want
to keep users from creating multi-terabyte databases all over the
place.
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Restricting schema sizes
@ 2010-10-17 19:45 Greg Smith <greg@2ndquadrant.com>
parent: Kieren Scott <kierenscott@hotmail.com>
1 sibling, 1 reply; 4+ messages in thread
From: Greg Smith @ 2010-10-17 19:45 UTC (permalink / raw)
To: Kieren Scott <kierenscott@hotmail.com>; +Cc: pgsql-admin
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Restricting schema sizes
@ 2010-10-20 16:22 Kieren Scott <kierenscott@hotmail.com>
parent: Greg Smith <greg@2ndquadrant.com>
0 siblings, 0 replies; 4+ messages in thread
From: Kieren Scott @ 2010-10-20 16:22 UTC (permalink / raw)
To: greg@2ndquadrant.com; +Cc: 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:
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
=
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2010-10-20 16:22 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2010-10-17 11:02 Restricting schema sizes Kieren Scott <kierenscott@hotmail.com>
2010-10-17 19:36 ` Scott Marlowe <scott.marlowe@gmail.com>
2010-10-17 19:45 ` Greg Smith <greg@2ndquadrant.com>
2010-10-20 16:22 ` Kieren Scott <kierenscott@hotmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox