Re: serverlog rotation/functions

Tom Lane wrote:

>Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
>
>
>>The attached patch includes serverlog rotation with minimal shared
>>memory usage as discussed and functions to access it.
>>
>>
>
>This patch is still unsafe and unworkable. Why would you make the
>mechanism dependent on shared memory *and* an intermediate data file
>*and* an inherited file handle to access that data file? The inherited
>handle is subject to race conditions (because you've got different
>processes fseeking the same file descriptor with no interlocking) and
>I don't really see that it's buying anything anyway. If you stored the
>value of time(NULL) to use in shared memory, you'd not need the data
>file because every process could compute the correct logfile name for
>itself.
>
>

'k, the timestamp may be used as a flag to reopen too, probably better
than that filehandle stuff. I can rewrite that.

>An issue that doesn't matter a whole lot on Unix, but I think would
>matter on Windows, is that with the patch as given a process will not
>reopen the log file until it's got something to write there. Non-chatty
>processes could easily hold open the old log file indefinitely. It
>might be a good idea to force the log file to be reopened at SIGHUP,
>and for the "rotate" command to do such a SIGHUP.
>
>

Why do you expect problems on win32 here? I intentionally did *not* tie
this to a SIGHUP, which I consider to be quite an expensive signal for
this case, to reopen a file that is (hopefully) rarely used. Imagine 100
backends, SIGHUPping every minute or so. But certainly a backend could
check for the logfile to be current when SIGHUP is received.

>Overall though, I still quite fail to see the point of doing it this
>way compared to piping the postmaster's stderr into something that can
>rotate log files. The fundamental objection to this whole feature is
>that it can only capture elog output, which is not everything of
>interest. (For example, dynamic linker failures will usually be
>reported to stderr, a behavior that we cannot override.)
>
>

If this "something" is tightly coupled to the postmaster, and can be
retrieved over a database connection, fine.
The restriction about messages going to stderr are valid for
log_destination syslog too, so the new log_destination=file is no
regression. What would you use on win32? Piping stderr isn't really
popular there, and eventlog is shared between all apps (that's probably
the reason why M$ uses an own log infrastructure for MSSQL).

Regards,
Andreas