Re: User Quota Implementation

From: Yann Michel <yann-postgresql(at)spline(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: josh(at)agliodbs(dot)com, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: User Quota Implementation
Date: 2005-06-10 19:18:48
Message-ID: 20050610191848.GB26490@zoom.spline.inf.fu-berlin.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tom,

On Fri, Jun 10, 2005 at 01:37:54PM -0400, Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > Yeah. I'd prefer per-database quotas, rather than per-user quotas, which
> > seem kind of useless. The hard part is making any transaction which
> > would exceed the per-database quota roll back cleanly with a
> > comprehensible error message rather than just having the database shut
> > down.
>
> That part doesn't seem hard to me: we already recover reasonably well
> from smgrextend failures. The real difficulty is in monitoring the
> total database size to know when it's time to complain. We don't
> currently make any effort at all to measure that, let alone keep track
> of it in real time.
>
> Given that there might be lots of processes concurrently adding pages
> in different places, I don't think you could hope for an exact
> stop-on-a-dime limit, but maybe if you're willing to accept some fuzz
> it is doable ...

Well I think a fuzzy test is better than none. But I think one should be
able to calculate how much later the quota is detected as exceeded than
it is planed to be. Therefor a threshold is usefull as well (for
alerting)

Regards,
Yann

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message ziga 2005-06-10 19:20:33 Re: Request for Comments: ALTER [OBJECT] SET SCHEMA
Previous Message Yann Michel 2005-06-10 19:16:15 Re: User Quota Implementation