On Mon, 19 Feb 2007, Alvaro Herrera wrote:

We already have a "combined GUC option" that is used to change two different things (DateStyle) and I regularly see people confused about how to use it.

You already have a combined GUC option called log_destination that's sitting in the appropriate area of the configuration file, doing something similar to what's needed for the new feature. People confused by that are already confused.

Also, "sql" is not really a destination -- it is a format.

A log file with a different name is another destination. eventlog is certainly a different format and it's sitting happily as an option there. I haven't heard anyone make a useful argument yet as to how insert/sql logs are any different than the current way that stderr, syslog, and eventlog are all possibilities now for log_destination, each with their own little quirks (and in the case of syslog, their own additional GUC parameters).

That way you can choose to have one or the other, or both if you're really dumb.

The fact that you're characterizing people who might want both as "really dumb" tells me you're not familiar with enterprise logging requirements. I already commented on situations where wanting both types of output going at once is going to absolutely be a requirement in some environments for this feature addition to be useful; there are a lot of large operations that rely heavily on features like syslog to help manage their systems. Most of the places I've worked at, the syslog server where the analysis is running wasn't necessarily even in the same state as the machine generating the log entries.

I know I can't deploy this feature unless it operates in parallel with the existing text-based info going to syslog, both because of that and because of transition issues--I can't disrupt the existing logs to test a new log mechanism until that new mechanism has proven itself. I'll probably deploy it with both turned on forever once it's available.

As for your comments on syslog vs. stderr, I completely agree with Guillaume's response to you on that subject. The stderr output is difficult to use for the reasons he describes, but the kind of environments that use complicated logging aren't relying on that anyway. I wouldn't get distracted by fixing that implementation when it's functional enough for most who are satisfied with stderr output.

* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to