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

Re: BUG #7559: syslogger doesn't close stdout and stderr

From: Reinhard Max <Reinhard(at)m4x(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7559: syslogger doesn't close stdout and stderr
Date: 2012-09-21 19:31:25
Message-ID: alpine.LNX.2.00.1209212110450.32722@albrecht.home.m4x.de (view raw or flat)
Thread:
Lists: pgsql-bugs
On Fri, 21 Sep 2012 at 14:17, Tom Lane wrote:

> All of the use-cases I've thought of for wanting to capture stderr 
> output for it amount to debugging of some form or other, so it's 
> probably good enough for that to only work in the first logger 
> incarnation after database start --- but Reinhard is proposing to 
> make it not work at all, and that I don't like.

No, I am proposing to have consistent behaviour between the first and 
subsequent incarnations by default and add a switch to turn on 
debugging mode for the first incarnation, if needed.

AFAICS the /dev/null redirection as per my patch would happen *after* 
postmaster and/or logger have had a chance to speak up about early 
errors that might prevent PostgreSQL from starting up at all, so 
errors that happen during startup in production scenarios won't be 
suppressed regardless where the user or init script redirects them.

Only stuff like the glibc memory debugging output you mentioned before 
(which only get produced when glibc itself runs in some debugging 
mode) would get suppressed by default if it happens after the 
syslogger has done the redirection.


cu
 	Reinhard


In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2012-09-24 02:36:00
Subject: Re: BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
Previous:From: Tom LaneDate: 2012-09-21 18:17:46
Subject: Re: BUG #7559: syslogger doesn't close stdout and stderr

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