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
