Обсуждение: Re: [PATCH] Fixed creation of empty .log files during log rotation

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

Laurenz Albe <laurenz.albe@cybertec.at> writes:
> 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.

Yes.  An important point here is that we must not assume that all
stderr output from a Postgres server process goes through elog.c.
It's possible to have random other stuff loaded, such as Python
modules invoked via PL/Python, and there's no guarantee that such
code won't write valuable information to stderr.  Another example
that doesn't require any extension at all is that if glibc detects
corruption of malloc'd memory, it will complain about that on
stderr.

So the argument that these .log files won't contain any useful
data is false.

A conceivable improvement is to make the logger unlink a log file if
it's still empty after we stop using it.  Even that would need a
switch IMO, since it might break somebody's log-archiving script.
But I'm doubtful that it's worth the trouble.

            regards, tom lane

On Tue, Nov 18, 2025 at 06:31:19PM -0500, Tom Lane wrote:
> So the argument that these .log files won't contain any useful
> data is false.
>
> A conceivable improvement is to make the logger unlink a log file if
> it's still empty after we stop using it.  Even that would need a
> switch IMO, since it might break somebody's log-archiving script.
> But I'm doubtful that it's worth the trouble.

FWIW, after reading again the thread and the arguments in place, I am
still not convinced that there is something to do here.
--
Michael