Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
