I wrote:
> The relevant bit of the code is
> /*
> * The requirements here are to choose the next time > now that is a
> * "multiple" of the log rotation interval. "Multiple" can be interpreted
> * fairly loosely. In this version we align to log_timezone rather than
> * GMT.
> */
Oh, no, scratch that --- there's nothing wrong with that calculation.
Actually I think the issue is with the logic that decides whether to
truncate or append during rotation:
* Decide whether to overwrite or append. We can overwrite if (a)
* Log_truncate_on_rotation is set, (b) the rotation was triggered by
* elapsed time and not something else, and (c) the computed file name is
* different from what we were previously logging into.
*
* Note: during the first rotation after forking off from the postmaster,
* last_file_name will be NULL. (We don't bother to set it in the
* postmaster because it ain't gonna work in the EXEC_BACKEND case.) So we
* will always append in that situation, even though truncating would
* usually be safe.
This dates from around 2004, and at the time we did not think it was
very important if the first rotation opportunity failed to truncate.
Of course, if you restart the postmaster so often that it never gets to
the second rotation opportunity, that theory falls down. But I guess
it's worth asking why you think it's a good plan to reboot so often.
Most people running Postgres are appalled by the idea that they might
have to have any downtime at all.
regards, tom lane
