Andrew Dunstan wrote:
>
>
> Alvaro Herrera wrote:
>> Andrew Dunstan wrote:
>>
>>> The attached patch makes a very small but useful change to the
>>> behaviour of log_line_prefix, by enabling the start time (%s) and
>>> cookie (%c) logging to occur for all backends rather than just for
>>> session processes (i.e. backends started for a client connection).
>>> We actually need almost all of this patch, with or without the
>>> change in behaviour, so we can put the cookie in CSVlogs (which I'm
>>> still working on), since the cookie+line number make the natural
>>> primary key for the logs. The actual change in behaviour from this
>>> patch comes from the removal of 2 "if (MyProcPort)" lines in elog.c.
>>> Given that, can I sneak this in or should I wait for 8.4 given we're
>>> long past feature freeze?
>>>
>>
>> Thinking again about the feature itself I wonder if it actually makes
>> sense -- maybe it does make sense to be able to display the session ID,
>> but the start time? Why would anyone care about the start time of
>> syslogger or bgwriter? We don't even have a use for the "hey, this
>> process was started" log line, why would anyone care about having the
>> start time in the log line prefix?
>>
>> Actually having the cookie in all processes is another matter, as far as
>> it's useful for CSV logs. But then, is it? Maybe the auxiliary
>> processes should identify themselves with fixed cookies or something
>> particular that lets one distinguish, say, a bgwriter from a syslogger,
>> but is there a case from distinguishing one bgwriter from another?
>>
>>
>
> It's not about distinguishing one bgwriter from another, it's about
> distinguishing it from any other process at any time whatsoever that
> has had the same pid. cookie+linenumber should be unique.
> pid+linenumber isn't. (And every process gets its own line number
> sequence, so we can't just give, say, all the bgwriter processes the
> same cookie). Logging the start time on its own isn't much extra
> benefit, although I expect log parsers will find it nicer to be able
> to handle a more consistent logging style rather than having to handle
> non-session processes as a special case. But having the cookie
> available in all cases is the whole point of this - I wouldn't have
> done it unless I had needed to be able to set a primary key for
> loadable logs.
>
> If you want to invent some other style of cookie we can look at that.
> Back when we looked at it originally nobody came up with a better
> suggestion than process_start.pid. But that surely would be for a
> later release ;-)
>
> So, short answer - yes, I think it makes sense. But if there's any
> serious argument I won't change the observable behaviour in elog.c,
> just the infrastructure.
>
>
In the absence of further discussion I have committed this.
That clears the decks for me to have yet another go at CSVlogs ;-)
cheers
andrew
