Skip site navigation (1) Skip section navigation (2)

Re: SOC & user quotas

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Martijn van Oosterhout <kleptog(at)svana(dot)org>,pgsql-hackers(at)postgresql(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Subject: Re: SOC & user quotas
Date: 2007-03-01 20:58:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Feb 28, 2007 at 02:29:52PM -0800, Joshua D. Drake wrote:
> > I don't know, but in my opinion, I don't see anything bad in requiring
> > dropping the data if the quota is full. That's what usually occurs in
> > the case of normal filesystem quota... If you don't have a space there,
> > you cannot edit files, copy them etc...
> > And that solution should be definitely better than the filesystem quota
> > for the PostgreSQL user for example.
> The bad point is not that we would rollback the transaction. The bad
> point is what happens when you need to rollback a transaction and in
> your scenario it is quite plausible that a large rollback could occur,
> more than once, causing the requirement of something like a vacuum full
> to clean things up.

ISTM that if the transaction is that big it's likely going to be
extending the heap, which means you'd get space back on a plain vacuum.

As for things like CLUSTER, and REINDEX it would probably be useful to
make an exception, since we know that those operations are intended to
shrink the size of a relation.

I also think there's a lot to be said for a soft limit.
Jim Nasby                                            jim(at)nasby(dot)net
EnterpriseDB      512.569.9461 (cell)

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-03-01 21:00:53
Subject: Re: Possible Bug: high CPU usage for stats collector in 8.2
Previous:From: Andrew DunstanDate: 2007-03-01 20:53:42
Subject: Re: Possible Bug: high CPU usage for stats collector in 8.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group