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

Re: enable logging of start time/cookie for all backend processes

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: enable logging of start time/cookie for all backend processes
Date: 2007-08-02 07:56:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches

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 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 response to


pgsql-patches by date

Next:From: Simon RiggsDate: 2007-08-02 14:37:32
Subject: Re: HOT patch - version 11
Previous:From: Pavan DeolaseeDate: 2007-08-02 07:33:08
Subject: Re: HOT patch - version 11

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