Re: more contrib: log rotator
От | Andrew Sullivan |
---|---|
Тема | Re: more contrib: log rotator |
Дата | |
Msg-id | 20030406225452.GC26918@libertyrms.info обсуждение исходный текст |
Ответ на | Re: more contrib: log rotator (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: more contrib: log rotator
Re: more contrib: log rotator |
Список | 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 по дате отправления: