Fixing syslogger rotation logic for first-time case
We've had a couple of complaints recently from people who were unhappy
because the syslogger's log_truncate_on_rotation logic does not fire
during the first log rotation after it's forked off from the postmaster.
The key reason for that was that to know whether to truncate or not,
the code has to know if the rotation actually changed to a new file
name, and it did not have that information inherited from the
postmaster. The attached patch deals with that problem by passing down
the pg_time_t that the log file name is computed from, and then
reconstructing the file name. This is kind of the hard way in Unix-oid
platforms: we could just let the malloc'd file name hang around through
the fork. But on Windows it would be necessary to include the file name
in the BackendParameters struct that's built on every child process
launch, and that seemed pretty costly, considering the overwhelming
majority of postmaster children don't need it. So I did it like this.
Any objections?
regards, tom lane
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]
On Behalf Of Tom Lane
We've had a couple of complaints recently from people who were unhappy
because the
syslogger's log_truncate_on_rotation logic does not fire during the first
log rotation > after it's forked off from the postmaster.
Any objections?
I have done the testing as per issue reported and below is result of same.
Configuration
----------------------
logging_collector = on
log_directory = 'pg_log'
log_filename = 'postgresql-%H.log'
log_truncate_on_rotation = on
log_rotation_age = 1h
log_rotation_size = 0
Behavior without the fix
--------------------------------
1. Problem was that on first time rotation syslogger was appending data.
Behavior After the Patch
--------------------------------
1. Startup time file should be appended. -- working fine
2. On first rotation it should truncate the log file -- working fine
With Regards,
Amit Kapila.