Re: [PATCH] Fixed creation of empty .log files during log rotation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Арсений Косицын <a(dot)kositsyn(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Fixed creation of empty .log files during log rotation
Date: 2025-11-18 23:31:19
Message-ID: 1354021.1763508679@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2025-11-18 23:38:17 Re: log_min_messages per backend type
Previous Message Masahiko Sawada 2025-11-18 23:15:11 Re: [PATCH] Add memory usage reporting to VACUUM VERBOSE