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

Re: Logging problems in PostgreSQL 7.2devel

From: John Summerfield <pgtest(at)os2(dot)ami(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: John Summerfield <pgtest(at)os2(dot)ami(dot)com(dot)au>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: Logging problems in PostgreSQL 7.2devel
Date: 2001-09-08 00:13:53
Message-ID: Pine.LNX.4.33.0109080811130.26020-100000@dugite.os2.ami.com.au (view raw or flat)
Thread:
Lists: pgsql-bugs
On Fri, 7 Sep 2001, Tom Lane wrote:


> John Summerfield <pgtest(at)os2(dot)ami(dot)com(dot)au> writes:
> > I have postmaster configured to use syslog. Despite this, these messages appear on the terminal from which I start it:
> > 2001-09-03 23:44:37 [26371]  DEBUG:  recycled transaction log file 0000000000000044
>
> Ah, I see what's causing that.  elog.c does this to decide whether to
> write on stderr:
>
> 	/* write to terminal */
> 	if (Use_syslog <= 1 || whereToSendOutput == Debug)
> 		write(2, msg_buf, strlen(msg_buf));
>
> Now, whereToSendOutput is initially Debug in a postmaster or standalone
> backend, and it gets changed to Remote when a normal backend is forked
> from the postmaster.  The messages that John is seeing come from routine
> checkpoint subprocesses, which are also forked off from the postmaster
> --- and whereToSendOutput is never changed in that path.
>
> It strikes me that perhaps we should have whereToSendOutput start out
> as None in a postmaster (but it should still be Debug in a standalone
> backend or bootstrap run).
>
> Peter, I'm cc'ing you since you've messed with elog message handling
> most recently.  Do you have any thoughts about proper behavior here?

I should also mention these debug messages occur despite my efforts to turn them off.



>


In response to

pgsql-bugs by date

Next:From: Larry RosenmanDate: 2001-09-08 02:06:18
Subject: CURRENT CVS: MULTIBYTE: CANT CONNECT....
Previous:From: Tom LaneDate: 2001-09-07 23:36:34
Subject: Re: backend closed the channel unexpectedly

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