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:

Previous
From: Pavel Stehule
Date:
Subject: actualized czech FAQ again
Next
From: Bruce Momjian
Date:
Subject: Re: First attempt: support for "\dg" in psql