Takahiro Itagaki escreveu:
> If you have better loggers already, why don't you use them? In another word,
> should we cooperate with them instead of re-inventing alternative loggers?
>
We can use but they don't features that our logger has. If we have a logger,
let's improve it.
> We have "Loggin
Tom Lane escreveu:
> (1) Windows compatibility?
>
Yes.
> (2) What happens if the command takes a significant amount of time to
> execute? We can't afford to have the log collector blocked.
>
You're right. We can't have that command in the same process because DBAs
could have high values for log
Euler Taveira de Oliveira wrote:
> other log management softwares have a way to do that so why our logger doesn't
> have such capability?
>
> I want to propose a new command to be execute after the log file is rotated. A
> GUC parameter log_after_rotation_command that takes a (set of) command(s
Euler Taveira de Oliveira writes:
> I want to propose a new command to be execute after the log file is
> rotated.
(1) Windows compatibility?
(2) What happens if the command takes a significant amount of time to
execute? We can't afford to have the log collector blocked.
(3) What do you intend
Hi,
We support several methods for logging server messages. The "native" methods
(stderr, csvlogs) has poor management. We can't compress logs, send them to
another location/server, or just remove old ones. Another problem is that we
can't remove (automatically) old logs based on the number of exi