Andrew Sullivan writes:
> PostgreSQL is not a system process, and I think it's a mistake to
> assume that it is.
The point is that PostgreSQL should fit nicely with the customs of the
system that it runs on. This starts with the oft-discussed file system
layout, the use of syslog in the first place, using 'cron' and 'at'
instead of rolling our own mechanisms to schedule jobs, as is occasionally
requested, fitting in with the startup scripts system, and so on.
> 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.
That is not the argument. What we need to do is to make it *possible* to
rotate the logs without shutting down the server, not (necessarily) do the
rotation ourselves. How can we even begin to do that? Do we need to
invent a configuration language that can control when to rotate, where to
move the old logs, when to delete the even older logs, etc.?
> 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.
That is an argument that manual vacuum is a liability, not the use of
cron for it.
--
Peter Eisentraut peter_e@gmx.net