Re: SOC & user quotas

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru>, pgsql-hackers(at)postgresql(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Subject: Re: SOC & user quotas
Date: 2007-03-01 23:56:56
Message-ID: 1172793416.13722.143.camel@dogma.v10.wvs
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2007-03-01 at 17:53 -0500, Tom Lane wrote:
> The real problem though is whether you can get anything much done if up
> against a hard limit; especially if that limit also affects the system
> catalogs. Remember that UPDATE requires the ability to insert new tuple
> versions, so there are a whole lot of things that will draw that ERROR.
>

You can pg_dump, drop the database, and make it again (maybe after
deleting a few lines).

I know it's not pretty, but the request is mostly centered around
virtual hosting. The admin can easily generate emails when space is low,
and when someone actually hits the quota the admin does have a path to
get them out of the mess without disturbing other customers.

It's not fool-proof. Someone can generate huge amounts of WAL traffic,
hog the CPU, use the RAM, all kinds of things. But virtual hosting can't
easily prevent that kind of thing anyway.

So it seems like we already have a solution to quotas at the database
level.

Another point is that shared virtual hosting is becoming less important
as OS virtualization (like Xen) becomes more prevalent.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message FAST PostgreSQL 2007-03-02 00:19:43 Re: [HACKERS]
Previous Message Hiroshi Saito 2007-03-01 23:44:56 Re: Removing some of the old VC++ stuff