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 23:47:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches

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 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 ;-)



In response to

pgsql-patches by date

Next:From: Magnus HaganderDate: 2007-08-03 10:47:16
Subject: Re: [PATCHES] patch win32.mak of libpq
Previous:From: Andrew DunstanDate: 2007-08-02 23:33:11
Subject: Re: use binary mode on syslog pipe on windows to avoid upsetting chunking protocol

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