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

Re: fsutil ideas

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Rod Taylor" <pg(at)rbt(dot)ca>
Cc: <pgsql-hackers(at)postgresql(dot)org>,"Neil Conway" <neilc(at)samurai(dot)com>,"Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov>
Subject: Re: fsutil ideas
Date: 2006-02-24 17:18:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
>>> On Fri, Feb 24, 2006 at 10:57 am, in message
Rod Taylor <pg(at)rbt(dot)ca> wrote: 
> PostgreSQL seems to deal with out of diskspace situations pretty
> when it impacts a tablespace (global stuff like WAL or
> have issues --  but they grow slowly) as far as only interrupting
> for the individual actions that ran out.

We haven't used tablespace features yet, as 3 of the 4 databases
running PostgreSQL so far are on Windows.  We have run out of space a
couple times, and it seems like it handles it well in terms of not
corrupting the database, and resuming OK once some space is freed.  The
messages are not that clear -- some sort of generic I/O write error, as
I recall, instead of "out of disk space" being clearly stated.

> You may wish to look at funding toggles that can configure the
> memory usage and maximum temporary diskspace (different tablespaces
> filesystem quotas) on a per user basis similar to the
> limitations in place today.

That wouldn't help because the vast majority of the work is done
through a middle tier which uses a connection pool shared by all users. 
It does take some human review and judgment to ensure that a query which
is running long and/or using a lot of temp table space is really a
problem as opposed to one of our larger legitimate processes.

> I'm curious as to how you monitor for total transaction time length
> ensure that vacuum is able to do its thing, particularly when the
> transaction is active (not IDLE).

We run a database vacuum nightly and review it the next day. 
(Something will need to be done to automate this with summaries and
exception lists when we get more than a few databases on PostgreSQL.  We
can't have a person reviewing 100 of these every day.)  We've not had
any nightly vacuum fail to finish.  They did start running a tad long
until we did some aggressive maintenance at one point.

Our autovacuum is configured with fairly aggressive parameters,
compared to the default; but, even so, only a few small tables with high
update rates normally reach the thresholds.  I haven't noticed the
autovacuum getting held up on these.


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2006-02-24 17:22:57
Subject: Re: fsutil ideas
Previous:From: Bruce MomjianDate: 2006-02-24 17:18:22
Subject: Re: [HACKERS] Patch Submission Guidelines

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