Re: WIP patch - INSERT-able log statements

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 gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD