On Tue, 20 Feb 2007, FAST PostgreSQL wrote:

I think adding the 'format' of the log as an option in the 'destination' may be confusing. We can have a new boolean variable like 'output_sql_log' or 'log_sql_format' which will trigger the output of INSERT-able log in addition to syslog/stderr/eventlog in text format as it is now.

What's confusing about it? Consider this hypothetical postgresql.conf snippet:

log_destination = 'stderr,sql'     # Valid values are combinations of
                    # stderr, syslog, sql, and eventlog,
                    # depending on platform.

# These are relevant when logging to sql:
log_sql_table = 'pg_log'  # Table SQL formatted logs INSERT into
                    # Default is 'pg_log'

Adding new GUC variables isn't without cost; no reason to add a new one when there's a perfectly good destination one already whose syntax is completely appropriate for this task.

I personally would just ignore the duration two entries per statement problem and make that the log analyzer software's job to fix, but I'm likely biased here because I don't ever do anything with that data.

My preference would be for the sql-logs to use the same variables as that of redirect_stderr. In the directory mentioned by the user on log_directory we just output the sql logs in a file with an '.SQL' appended to the filename specified by the user in log_filename. This also means we can make use of the log_truncation and log_rotate options (I hope. I will have a look at that).

You're talking along the same lines here I was trying to suggest in my previous message. Keep all the current behavior as far as truncation and rotation go, just provide a different name for the file. If you just appended a suffix like .sql to the existing name, that would remove another GUC variable requirement. I think eventually people will complain about this, and want a separately formatted filename altogether, but there's nothing wrong with the approach you suggest for a first version of this feature. I know I'm so desparate for a better solution to log importing that I'd be happy with any workable improvement.

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to