On Tue, 2024-10-29 at 11:08 +0300, Арсений Косицын wrote:
> log_destination = 'csvlog'
> logging_collector = on
> log_rotation_age = 1min
> log_directory = '/home/user/builds/postgresql/log'
>
> 2) After starting the server, two files are being created in the directory with logs:
>
> -rw------- 1 user user 1,4K oct 10 13:29 postgresql-2024-10-10_132907.csv
> -rw------- 1 user user 172 oct 10 13:29 postgresql-2024-10-10_132907.log
>
> 3) The .log file is created anyway, regardless of the log_destination parameter.
> [...]
>
> Next, the stderr stream is redirected to a .csv file.
>
> 4) Now, logs are rotated once a minute (due to the set log_rotation_age parameter). Moreover, all
> open log files are rotated, including the .log file that I wrote about above. New ones are being created
> .csv and .log files. Logs themselves are sent to .csv, and nothing else is output to .log
> and it remains empty:
>
> --Fix:
>
> To correct the situation, you can add a check for the "Log_destination" parameter in the "logfile_rotate()"
> function of the "syslogger.c" module. Then only the logs specified in this parameter will be rotated.
> This is done in the proposed patch.
I see your point, but I am having doubts.
You say that the stderr stream is redirected to the CSV file, but that is not true.
Anything that a PostgreSQL process writes to stderr will still end up in the *.log file.
For example, any error message from the archive_command will end up there, not in the
CSV log.
I think that that is pretty useful.
Where do such messages end up with your patch? I didn't test, but I guess they'll
just be written to the console and get lost.
The empty (or almost empty) *.log files are not pretty, but are they a problem
to solve at the price of losing potentially interesting information?
Yours,
Laurenz Albe
