If it's not going into the distribution as contrib or core, I'll package that as additional admin pack. I'm quite sure I can convince the win32 installer packager guys to include that as default-on option as soon as I'm able to prove them how it's working.
Uh, but it isn't working on Win32, right? How do you fix that? During beta? That would be OK as an add-on.
As I said, I'm going to fix the stderr issue. This will enable the pending log rotation stuff more or less incidentially.
The win32 log issue isn't a serverlog rotation issue, as I stated also the current stderr output is affected! I'd clearly see that as a fix, whilst it might be more than 10 lines of code. I'll try to fix that tomorrow. The very log_destination=file and rotation code will be more or less the same as for ***x.
But does it work on Win32 and Unix? It has to.
I meant to implement that stderr handling stuff for win32, in order to have a clean stderr output. Unix isn't affected, it works as posted.
Yes, that is a problem but we have to cut or we will never get to beta. Probably doing an add-on until 7.6 might be the best but you are working on it so let's see.
The add-on are the functions, not the log rotation. Log rotation for unix is beta-ready, and virtually unchanged for weeks now. It will be available shortly for win32 too, as soon as the stderr piping issue is solved. I'm a bit tired of arguing, that's why I didn't split the functions in a part that was proposed together with the core functionality before feature freeze and an additional part. I feel that the majority of installations (win32) will have them anyway.
Regards, Andreas
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
