Andrew Dunstan <andrew@dunslane.net> writes: > I can't see any very good reason for text logs to have different > content from CSV logs. 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? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

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. 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. 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? regards, tom lane ---------------------------(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

Andrew Dunstan <andrew@dunslane.net> writes: > Tom Lane wrote: >> 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. Well, I don't see that "{some text,more text,yet more text}" is going to be harder to cram into the average CSV-reader than "some text more text yet more text". However, in most cases split_to_array on newlines would be a good enough way of deconstructing the field in Postgres, so maybe it's not worth worrying about. Anyway, I think that we should just make the CSV fields be the same as the existing divisions in the textual log format, which seem to have stood up well enough in use since 7.4 or whenever we put that scheme in. regards, tom lane ---------------------------(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

Andrew Dunstan <andrew@dunslane.net> writes: > If it's about what to quote, we need to quote anything that might > contain a newline, quote or comma. Filenames certainly come into that > category. These are not general file paths, these are base names of our own C source code files. I don't have a problem with legislating that we will never have such characters in backend source file names ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Another change I did was to change a "%.*s" to "%*s". The "precision" > marker seems useless AFAICT. This is wrong, broken, will cause crashes on platforms where the PS string is not null-terminated. (Hint: .* is a maximum width, * is a minimum width.) Another thing I thought strange was the order of the added columns; why isn't it more like the order in which they appear in the text version? In particular hint should probably come just after detail and before context, and internal-query should also come before context because when relevant it's usually more closely nested than the context stack. Otherwise the patch looks pretty sane to me. I didn't do any testing though. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings

Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > I still propose that the log line number should be moved w.r.t. session > identifier. No objection here. > I changed two more things: the VXID is not reported if not in a backend > (because AuxiliaryProcesses are said to never have one), and added > quotes surrounding the hostname, because in a test here it seems > supported to create an alias for my loopback interface with a name like > "a,b". Sounds reasonable, as long as autovac processes still report VXID. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly