Re: [BUGS] BUG #3799: csvlog skips some logs

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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