On Saturday 13 March 2004 01:00 pm, Fernando Nasser wrote:
There are some applicatons which run in servers with very strict response times and any syscall, network packet that can be saved counts.
Ok, what about pipe overhead? If we're gong to split hairs, let's split all of them. The design of the pipeline in this logrotator filter will have to be such that minimal overhead occurs, because, at the real-time level, every concurrent process also counts.
Splitting hairs was not my intention :-) But there is always something to gain or learn from a good debate...
What you say is true. Nobody seems to consider that there si some overhead in piping as well. Perhaps it is another (unproved?) belief that it will not be as significant as using a central syslog service.
The number of generated messgaes.
Maybe that is an area that can be worked on, i.e. reducing log verbosity. Is 7.4.x much better than 7.3.x in that respect?
There are several levels documented in postgresql.conf. Try the terse level and see what happens.
It used to be that if you lowered it too much you would get fewer messages but not enough information. There is a tendency that this improves with time, I would guess.
There are cases where a problem is suspected and then users have to raise the log level in the hopes that it gives them some clue when the problem manifests itself (which sometimes, at least on a first instance, only happens in the production environment as is triggered by some weird usage pattern).
Best regards, Fernando
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
