Re: BUG #7814: Rotation of the log is not carried out.

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> For what it is worth, I can reproduce this on Windows 7, using the
> 9.2.2 and 9.1.7 windows 64 installers from EDB (i.e.
> http://www.enterprisedb.com/postgresql-922-installers-win64?ls=Crossover&type=Crossover),
> with completely default installation (EDB changes the default to be
> logging_collector=on), and using the below to blow up the log files
> with error messages:

> perl -le 'print "FOO$_;" foreach 1..1e7' | psql

> 9.1.7 rotates the log files in $DATA/pg_log, while 9.2.2 does not
> rotate based on size.

[ scratches head for awhile... ] Hm, what you are testing is the
default rotation parameters, right? log_rotation_age = 1 day,
log_rotation_size = 10MB? So you didn't wait to see what would happen
at a rotation-age boundary. If so, does "pg_ctl reload" kick it into
rotating once the file is too big? (Or you could reduce
log_rotation_age to a small value, but that would make it hard to
tell which condition triggered rotation.)

Here's what I think is probably happening: on Windows, the syslogger
process actually contains two threads, one of which handles data
transfer while the other worries about things like log rotation.
In prior versions, the control thread woke up once a second, so it
would notice within one second if the data transfer thread had filled
the current file to more than log_rotation_size. In 9.2, we got rid
of those "unnecessary" wakeups, which means log rotation won't occur
until there's some other event that kicks the control thread into
activity.

There's no bug on non-Windows because we don't use two threads on other
platforms; data transfer is done by the main thread so it's already
awake upon any write to the log file, and it won't miss the rotation
condition. (Size-based rotations were therefore always more precise on
non-Windows machines...)

So what we need on Windows is for the data transfer thread to notice
when "Log_RotationSize > 0 && ftell(syslogFile) >= Log_RotationSize",
and then either signal the control thread to wake up, or do the
rotation itself. Probably the former is less risk.

I'm not coding this fix though, since I'm not in a position to test it.

regards, tom lane