Andreas Pflug <pgadmin@pse-consulting.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.
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.
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.)
regards, tom lane