On Thursday 01 March 2007 17:35, Andrew Dunstan wrote:
> Tom Lane wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >> Andrew Dunstan wrote:
> >>> Hitting a file system quota limit is likely to bring you down pretty
> >>> hard, isn't it?
> >>
> >> Yes, and likely corrupt the database.
> >
On Fri, 2007-03-02 at 03:31 +0300, Sergey E. Koposov wrote:
> > So it seems like we already have a solution to quotas at the database
> > level.
>
> I still don't understand how FS quotas can help with DB quotas. ..
> All the FS quotas are setup for limiting the space for specific user and
> sp
On Thu, 1 Mar 2007, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
I still don't understand how FS quotas can help with DB quotas. ..
All the FS quotas are setup for limiting the space for specific user and
specific mount point. AFAIK They do not allow to limit the space in o
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> I still don't understand how FS quotas can help with DB quotas. ..
> All the FS quotas are setup for limiting the space for specific user and
> specific mount point. AFAIK They do not allow to limit the space in one
> directory. And since all th
So it seems like we already have a solution to quotas at the database
level.
I still don't understand how FS quotas can help with DB quotas. ..
All the FS quotas are setup for limiting the space for specific user and
specific mount point. AFAIK They do not allow to limit the space in one
dir
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
Jeff Davis <[EMAIL PROTECTED]> writes:
> Is it possible to make the database safe in this case? I can see why it
> would be difficult to handle pg_xlog filling up (or for that matter
> pg_log), but couldn't any other area be turned into just a simple ERROR?
It is --- Josh is mistaken about the sev
On Thu, 2007-03-01 at 14:13 -0800, Joshua D. Drake wrote:
> Andrew Dunstan wrote:
> > Jeff Davis wrote:
> >>
> >> If we allowed an admin to revoke CREATE from the pg_default tablespace,
> >> then anyone who needed that feature could limit people to their own
> >> tablespace (at which point it's the
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
Hitting a file system quota limit is likely to bring you down pretty
hard, isn't it?
Yes, and likely corrupt the database.
As long as you don't keep WAL on the restricted filesystem,
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Hitting a file system quota limit is likely to bring you down pretty
>> hard, isn't it?
> Yes, and likely corrupt the database.
As long as you don't keep WAL on the restricted filesystem, it won't
stop or corrupt your databa
Andrew Dunstan wrote:
> Jeff Davis wrote:
>>
>> If we allowed an admin to revoke CREATE from the pg_default tablespace,
>> then anyone who needed that feature could limit people to their own
>> tablespace (at which point it's the filesystem's job to limit their
>> usage). Is there some reason that
Jeff Davis wrote:
If we allowed an admin to revoke CREATE from the pg_default tablespace,
then anyone who needed that feature could limit people to their own
tablespace (at which point it's the filesystem's job to limit their
usage). Is there some reason that we can't do this now?
Hitting
Jeff Davis <[EMAIL PROTECTED]> writes:
> If we allowed an admin to revoke CREATE from the pg_default tablespace,
> then anyone who needed that feature could limit people to their own
> tablespace (at which point it's the filesystem's job to limit their
> usage). Is there some reason that we can't d
On Wed, 2007-02-28 at 12:56 -0500, Tom Lane wrote:
> "Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> > Per user AND per database (as Tom noted). But I dont see what's odd in
> > it... It exists in Oracle, and I need quotas in the project on which I'm
> > working. And I remember user requests f
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,
> > yo
> > Then you cannot run any queries that extend the size of
> your relations
> > (for example INSERT, UPDATE etc.). Unless you drop your tables or
> > DELETE something
>
> Interesting. Well my two cents is don't go any deeper than database.
> I.e; don't try and track to the individual relation
On Wed, 28 Feb 2007, Robert Treat wrote:
Sergey, could you do a little research on what behavior other databases that
support user quotes exhibit? This might help folks judge whether any
proposed solution for postgres will be above or below potential users
expectations.
Ok, I will.
Regards,
On Wednesday 28 February 2007 18:02, Sergey E. Koposov wrote:
> On Wed, 28 Feb 2007, Joachim Wieland wrote:
> > On Wed, Feb 28, 2007 at 12:56:13PM -0500, Tom Lane wrote:
> >> It hasn't ever made it onto the TODO list, which means there's not a
> >> consensus that we need it.
> >
> > Such a patch co
On Wed, 28 Feb 2007, Joachim Wieland wrote:
On Wed, Feb 28, 2007 at 12:56:13PM -0500, Tom Lane wrote:
It hasn't ever made it onto the TODO list, which means there's not a
consensus that we need it.
Such a patch could improve the acceptance of PostgreSQL in shared hosting
environments. Note th
On Wed, 28 Feb 2007, Joshua D. Drake wrote:
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
On Wed, Feb 28, 2007 at 12:56:13PM -0500, Tom Lane wrote:
> It hasn't ever made it onto the TODO list, which means there's not a
> consensus that we need it.
Such a patch could improve the acceptance of PostgreSQL in shared hosting
environments. Note that a database without quotas can be filled up
> 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 definit
On Wed, Feb 28, 2007 at 03:57:56PM -0500, Tom Lane wrote:
> It's worse than that, because VACUUM FULL will actually bloat the
> indexes on the way to being able to reduce the table size (since it has
> to make new index entries for rows it moves). If the limit is strictly
I was thinking that inde
On Wed, 28 Feb 2007, Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Martijn van Oosterhout wrote:
Generally, rolling back a transaction doesn't reduce the amount of disk
used. Only VACUUM FULL actually shrinks relations.
Right, but what I mean was -- if we rollback because we
On Wed, 28 Feb 2007, Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Martijn van Oosterhout wrote:
Generally, rolling back a transaction doesn't reduce the amount of disk
used. Only VACUUM FULL actually shrinks relations.
Right, but what I mean was -- if we rollback because we
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout wrote:
>> Generally, rolling back a transaction doesn't reduce the amount of disk
>> used. Only VACUUM FULL actually shrinks relations.
> Right, but what I mean was -- if we rollback because we hit quota we
> could potentially
On Wed, 28 Feb 2007, Joshua D. Drake wrote:
Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
Per user AND per database (as Tom noted). But I dont see what's odd in
it... It exists in Oracle, and I need quotas in the project on which I'm
working. And I remember user requests for
Martijn van Oosterhout wrote:
> On Wed, Feb 28, 2007 at 09:58:52AM -0800, Joshua D. Drake wrote:
>> E.g; if user foo then pg_database_size may not be > than X?
>>
>> I guess the big question would be when do we check though? At each
>> transaction seems like it would add significant overhead, espec
On Wed, Feb 28, 2007 at 09:58:52AM -0800, Joshua D. Drake wrote:
> E.g; if user foo then pg_database_size may not be > than X?
>
> I guess the big question would be when do we check though? At each
> transaction seems like it would add significant overhead, especially if
> we had to rollback the t
On Wed, 28 Feb 2007, Tom Lane wrote:
2) I looked into the code, and from my understanding, the main part of the
code which should be affected by the quotas is storage/smgr/md.c.
md.c is too low level to do catalog accesses and thus too low level to
know who owns what.
That's probably a dumb q
Tom Lane wrote:
> "Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
>> Per user AND per database (as Tom noted). But I dont see what's odd in
>> it... It exists in Oracle, and I need quotas in the project on which I'm
>> working. And I remember user requests for quotas in the mailing lists ...
>
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> Per user AND per database (as Tom noted). But I dont see what's odd in
> it... It exists in Oracle, and I need quotas in the project on which I'm
> working. And I remember user requests for quotas in the mailing lists ...
It hasn't ever made it
> Then you cannot run any queries that extend the size of your relations
> (for example INSERT, UPDATE etc.). Unless you drop your tables or DELETE
> something
Interesting. Well my two cents is don't go any deeper than database.
I.e; don't try and track to the individual relation.
Joshua D. Drak
On Wed, 28 Feb 2007, Joshua D. Drake wrote:
Sergey E. Koposov wrote:
On Wed, 28 Feb 2007, Joshua D. Drake wrote:
Per user AND per database (as Tom noted). But I dont see what's odd in
it... It exists in Oracle, and I need quotas in the project on which I'm
working. And I remember user requests
Sergey E. Koposov wrote:
> On Wed, 28 Feb 2007, Joshua D. Drake wrote:
>
>> I could see this being useful per database, maybe. It seems like kind of
>> an odd feature.
>
> Per user AND per database (as Tom noted). But I dont see what's odd in
> it... It exists in Oracle, and I need quotas in the
On Wed, 28 Feb 2007, Joshua D. Drake wrote:
I could see this being useful per database, maybe. It seems like kind of
an odd feature.
Per user AND per database (as Tom noted). But I dont see what's odd in
it... It exists in Oracle, and I need quotas in the project on which I'm
working. And I
On Wed, 28 Feb 2007, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
1) The main idea is to implement the per-user quota (not per tablespace
for example). So, during the creation of the new user some quota can be
specified, and after that the size of all the relations *owned* by
Sergey E. Koposov wrote:
> Hello hackers,
>
> I was starting to think about next SOC and the project for it. And for a
> long time I wanted to implement the user quotas in PG.
> So, I'll try to explain my understanding of the implementation, and I'll
> be happy to hear any comments, objections, or
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> 1) The main idea is to implement the per-user quota (not per tablespace
> for example). So, during the creation of the new user some quota can be
> specified, and after that the size of all the relations *owned* by that
> user should be limited b
39 matches
Mail list logo
