Received: from localhost (unknown [200.46.204.183])
	by developer.postgresql.org (Postfix) with ESMTP id 7610E2E002F
	for <pgsql-performance-postgresql.org@developer.postgresql.org>;
	Thu, 15 May 2008 12:56:36 -0300 (ADT)
Received: from developer.postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 11338-06
	for <pgsql-performance-postgresql.org@developer.postgresql.org>;
	Thu, 15 May 2008 12:56:33 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.mnc.ch (62-2-77-205.static.cablecom.ch [62.2.77.205])
	by developer.postgresql.org (Postfix) with ESMTP id 6F4F82E002D
	for <pgsql-performance@postgresql.org>;
	Thu, 15 May 2008 12:56:33 -0300 (ADT)
Received: from localhost (mail2.mnc.ch [127.0.0.1])
	by mail.mnc.ch (Postfix) with ESMTP id 5764123079
	for <pgsql-performance@postgresql.org>;
	Thu, 15 May 2008 15:56:32 +0000 (GMT)
X-Virus-Scanned: amavisd-new at mnc.ch
Received: from mail.mnc.ch ([127.0.0.1])
	by localhost (mail2.mnc.ch [127.0.0.1]) (amavisd-new, port 10025)
	with ESMTP id ons9SuRFIxrD for <pgsql-performance@postgresql.org>;
	Thu, 15 May 2008 15:56:31 +0000 (GMT)
Received: from meuh.localdomain (62-2-77-204.static.cablecom.ch [62.2.77.204])
	by mail.mnc.ch (Postfix) with ESMTP id C7A7123073
	for <pgsql-performance@postgresql.org>;
	Thu, 15 May 2008 15:56:31 +0000 (GMT)
Received: by meuh.localdomain (Postfix, from userid 1000)
	id B7EC4183677; Thu, 15 May 2008 17:56:31 +0200 (CEST)
To: "pgsql-performance\@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: which ext3 fs type should I use for postgresql
References: <1210846262.16664.41.camel@philippe-desktop>
	<Pine.LNX.4.64.0805151217490.16756@aragorn.flymine.org>
	<482C4F3D.6010808@emolecules.com> <87ve1fwqov.fsf@mnc.ch>
	<Pine.LNX.4.64.0805151618520.16756@aragorn.flymine.org>
	<87r6c3wpka.fsf@mnc.ch> <482C58EA.5090904@commandprompt.com>
From: Guillaume Cottenceau <gc@mnc.ch>
X-Hashcash: 
 1:20:080515:pgsql-performance@postgresql.org::KAQHXmsq9XcQN2zb:000000000000000000000000000000ksn
Date: Thu, 15 May 2008 17:56:31 +0200
In-Reply-To: <482C58EA.5090904@commandprompt.com> (Joshua D. Drake's message
	of "Thu\, 15 May 2008 08\:38\:18 -0700")
Message-ID: <87lk2bwogg.fsf@mnc.ch>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200805/223
X-Sequence-Number: 30191

"Joshua D. Drake" <jd 'at' commandprompt.com> writes:

> Guillaume Cottenceau wrote:
>> Matthew Wakeling <matthew 'at' flymine.org> writes:
>
>> It is still relevant, as with 5% margin, you can afford changing
>> that to 0% with tune2fs, just the time for you to start PG and
>> remove some data by SQL, then shutdown and set the margin to 5%
>> again.
>
> I find that if you actually reach that level of capacity failure it is
> due to lack of management and likely there is much lower hanging fruit
> left over by a lazy dba or sysadmin than having to adjust filesystem
> level parameters.
>
> Manage actively and the above change is absolutely irrelevant.

Of course. I didn't say otherwise. I only say that it's useful in
that case. E.g. if you're using a dedicated partition for PG,
then a good solution is what I describe, rather than horrifyingly
trying to remove some random PG files, or when you cannot
temporarily move some of them and symlink from the PG partition.
I don't praise that kind of case, it should of course be avoided
by sane management. A bad management is not a reason for hiding
solutions to the problems that can happen!

-- 
Guillaume Cottenceau