Re: more contrib: log rotator - Mailing list pgsql-hackers

From Andrew Sullivan
Subject Re: more contrib: log rotator
Date
Msg-id 20030406225452.GC26918@libertyrms.info
Whole thread Raw
In response to Re: more contrib: log rotator  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: more contrib: log rotator  (Lamar Owen <lamar.owen@wgcr.org>)
Re: more contrib: log rotator  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Mon, Apr 07, 2003 at 12:42:34AM +0200, Peter Eisentraut wrote:
> 
> My point was that log file rotation should be left up to the system
> administrator.  Look at other servers on your system (SMTP, DNS,
> whatever).  How do they handle it?

PostgreSQL is not a system process, and I think it's a mistake to
assume that it is.  We, for instance, do not have root on the
machines we use.  It's important to assume that users needn't be
system administrators to use the system.

I suppose, however, you could make the argument that log rotation
should be the responisibility of the adminisistrator of the
PostgreSQL server.  But that just amounts to an argument that nothing
needs to be done: as we see, there are lots of log management
facilities on offer, and none of them are included with PostgreSQL. 
I don't feel strongly about which one to use.  But since people
frequently complain that the feature is not available in PostgreSQL,
it does seem that, if it's not too much trouble, adding the feature
is worth it.

> > But that dependency is actually a liability, because there's no way
> > to say, "Hey, I really need to be vacuumed now."
> 
> psql -c 'VACUUM' ?

I meant on the part of the back end.  If you have a busy system on
which some tables need very frequent vacuuming, but it gets
unpredictable traffi, you don't just want to say, "Heck, let's vacuum
every hour."  You want to know _actually_ whether the table needs
vacuuming.

So you come up with a bunch of profiles, &c., and do a pile of work
to figure out which tables really need attention.  But that's not
free: it takes cycles on the machine, and the hypotheical case is one
in which the machine is already under heavy load.  So cron is not
really the answer.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8                                        +1 416 646 3304
x110



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: more contrib: log rotator
Next
From: Kevin Brown
Date:
Subject: Re: contrib and licensing