Re: serverlog rotation/functions - Mailing list pgsql-patches
From | Andreas Pflug |
---|---|
Subject | Re: serverlog rotation/functions |
Date | |
Msg-id | 40EACDDC.5060701@pse-consulting.de Whole thread Raw |
In response to | Re: serverlog rotation/functions (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: serverlog rotation/functions
(Andreas Pflug <pgadmin@pse-consulting.de>)
|
List | pgsql-patches |
Tom Lane wrote: >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. > > '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
pgsql-patches by date: