Hi Josh,
On Fri, Jun 10, 2005 at 02:25:11PM -0700, Josh Berkus wrote:
> > O.K. This makes sens to me. Otherwise I'd like to see quotas per
> > tablespace. As far as I got it, a tablespace may grow in size untile the
> > volume is full. Here a grace quota might be usefull as well. Let's say a
> > 5% threshold like the ext filesystem as an default for generating a
> > warning to th elogs files letting the admin extend the volum(s) by time.
>
> Hmmm ... Tablespace quotas would be *even more* useful than database
> quotas. If it's just as easy for you?
Well, lets see...
What do we need:
- Extension of the "CREATE TABLESPACE" command:
CREATE TABLESPACE tablespacename
[ OWNER username ]
[ SIZE <integer><K | M | G | T> ]
LOCATION 'directory'
- Extension of the "ALTER TABLESPACE" command:
ALTER TABLESPACE name
{RENAME TO newname |
SIZE <integer><K | M | G | T> }
- Storage of this information in the system "tablespace" relation
- Determine the actual size of a tables space
--> Already exists in contrib/dbsize/dbsize.c
- Define the point in time where this calculation should happen.
That's the point where I think some lazyness may appear, i.e. it is
enough to evaluate the size from time to time but not after each
statement. Of cause this will enable that a tablespace may become to
large but once it is to large, further extensions of it will become
prohibited.
- Define how to disable further extension of tablespace objects or
creation of new ones.
- Optional: Define postgresql.conf parameter:
"tablesspace_full_warning = 90"
Whenever the threshold of 90 percent is reached a warning will
be generated (and written to the log-files)
So far from me about my thoughts...
Regards,
Yann
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
