--0-940354931-1215157332=:34075
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Thanx for all the suggestions. I'm planning to go ahead with the trigger
ap=
proach and locking databases for writes when it goes over the threshold!
Se=
tting hard limits looks like a bad idea !
cheers
/Dev
--- On Thu, 7/3/08, Tino Schwarze <postgresql@[EMAIL PROTECTED]
> wrote:
From: Tino Schwarze <postgresql@[EMAIL PROTECTED]
>
Subject: Re: [ADMIN] Best way to limit database sizes
To: pgsql-admin@[EMAIL PROTECTED]
Thursday, July 3, 2008, 9:17 PM
On Thu, Jul 03, 2008 at 09:10:47PM +0200, Dimitri Fontaine wrote:
> >I've considered creating a tablespace in a directory owned by the=20
> >user , so I can use Linux quotas to prevent higher disk usage , but =20
> >this turned out be a bad thought, as all the files are anyway owned =20
> >by the postgres user and so disk quotas won't have any effect.
>=20
> What if you put each tablespace on a LVM partition of a control sized, =
=20
> extensible?
This is a desaster waiting to happen. I'd say never let a database get
out of disk space. Rather implement soft limits like regular cron jobs
and make them pay for overusage.
Also note that DB size on disk and amount of data stored in DB might be
a lot different because of bloating issues, indices etc.
Tino..oO(But LVM/tablespace should work.)
--=20
"What we nourish flourishes." - "Was wir n=E4hren erbl=FCht."
www.craniosacralzentrum.de
www.forteego.de
--=20
Sent via pgsql-admin mailing list (pgsql-admin@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin=0A=0A=0A
--0-940354931-1215157332=:34075
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
<table cellspacing=3D'0' cellpadding=3D'0' border=3D'0' ><tr><td
valign=3D'=
top' style=3D'font: inherit;'>Thanx for all the suggestions. I'm planning
t=
o go ahead with the trigger approach and locking databases for writes when
=
it goes over the threshold! Setting hard limits looks like a bad idea
!<br>=
<br>cheers<br><br>/Dev<br><br><br>--- On <b>Thu, 7/3/08, Tino Schwarze
<i>&=
lt;postgresql@[EMAIL PROTECTED]
></b> wrote:<br><blockquote
style=3D"border-lef=
t: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From:
=
Tino Schwarze <postgresql@[EMAIL PROTECTED]
>Subject: Re: [ADMIN] Best way
t=
o limit database sizes<br>To: pgsql-admin@[EMAIL PROTECTED]
>Date:
Thursday,=
July 3, 2008, 9:17 PM<br><br><pre>On Thu, Jul 03, 2008 at 09:10:47PM
+0200=
, Dimitri Fontaine wrote:<br><br>> >I've considered creating a
tables=
pace in a directory owned by the <br><br>> >user , so I can use
Linux=
quotas to prevent higher disk usage , but <br>> >this turned out
be=
a
bad thought, as all the files are anyway owned <br>> >by the
postgr=
es user and so disk quotas won't have any effect.<br>> <br>> What if
=
you put each tablespace on a LVM partition of a control sized, <br>>
ex=
tensible?<br><br>This is a desaster waiting to happen. I'd say never let a
=
database get<br>out of disk space. Rather implement soft limits like
regula=
r cron jobs<br>and make them pay for overusage.<br><br>Also note that DB
si=
ze on disk and amount of data stored in DB might be<br>a lot different
beca=
use of bloating issues, indices etc.<br><br>Tino..oO(But LVM/tablespace
sho=
uld work.)<br><br>-- <br>"What we nourish flourishes." - "Was wir n=E4hren
=
erbl=FCht."<br><br>www.craniosacralzentrum.de<br>www.forteego.de<br><br>--
=
<br>Sent via pgsql-admin mailing list (pgsql-admin@[EMAIL PROTECTED]
)<br>To
ma=
ke changes to your
subscription:<br>http://www.postgresql.org/mailpref/pgsq=
l-admin</pre></blockquote></td></tr></table><br>=0A=0A
--0-940354931-1215157332=:34075--


|