Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Well, if we want to cram all that stuff in there, how shall we do it?
It seems wrong to put all those lines into one text field, but I'm
not sure I want to add six more text fields to the CSV format
either. Thoughts?
Really? Six? In any case, would that be so bad? It would mean six extra
commas per line in the log file, and nothing much in the log table
unless there were content in those fields.
Yeah --- the lines output in the plain-stderr case that are not covered
in the other are
DETAIL
HINT
QUERY (this is an internally-generated query that failed)
CONTEXT (think "stack trace")
LOCATION (reference to code file/line reporting the error)
STATEMENT (user query that led to the error)
One issue here is that CONTEXT is potentially multiple lines. I'm not
sure that there is much we can do about that, especially not at the last
minute. If we had some time to rewrite internal APIs it might be fun to
think about emitting that as array of text not just text, but I fear
it's much too late to consider that now.
I'm not sure that putting all this into a single extra field would be so
wrong. As for an array of text, that doesn't seem very portable. I don't
think we should assume that Postgres is the only intended program
destination of CSV logs.
Another thing that I notice is that the CSV code emulates a couple of
not-very-orthogonal behaviors of send_message_to_server_log():
substituting "missing error text" for a NULL error field, and emitting
cursor pos as a tack-on to the error text instead of a separate field.
I think both of those are less than defensible. So if you're willing
to entertain redefining the CSV column set at this late date, I'd
propose throwing in a seventh new field too: CURSORPOS.
Seems like over-egging the pudding to me somewhat, but OK if we decide
to go with a whole bunch of fields.
Another thing: for stderr output, we have various log verbosity options
that determine whether these additional fields get printed. Should
those options also function in the CSV-output case, or are we just going
to do our best to exhaust disk space as fast as possible all the time?
I think for sanity's sake we need one (maximal) format. I'm not so
concerned about disk space. It's not like this is the only logging
option available.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
