Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: depesz <depesz(at)depesz(dot)com>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] BUG #3799: csvlog skips some logs
Date: 2007-12-07 02:19:39
Message-ID: 6388.1196993979@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2007-12-07 03:19:44
Subject: Re: [HACKERS] "distributed checkpoint"
Previous:From: Tom LaneDate: 2007-12-07 01:44:49
Subject: Re: "distributed checkpoint"

pgsql-bugs by date

Next:From: Kris JurkaDate: 2007-12-07 02:40:59
Subject: Re: BUG #3801: max_fsm_pages postgresql.conf default != guc.c default
Previous:From: Reece HartDate: 2007-12-07 02:01:38
Subject: Re: BUG #3801: max_fsm_pages postgresql.conf default !=guc.c default

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group