Re: Proposal: leave a hint when switching logging away from stderr

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Proposal: leave a hint when switching logging away from stderr
Date: 2013-08-10 14:57:56
Message-ID: 14412.1376146676@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Fri, Aug 09, 2013 at 06:59:13PM -0400, Tom Lane wrote:
>> Also, I'm not sure that the chattiness argument is relevant, because no
>> message will be emitted at all unless you're switching to some log target
>> different from the postmaster's initial stderr. So the message won't show
>> up in the "official" log target files, only in an arguably vestigial
>> startup-time-messages-only file.

> Perhaps the chatter would most affect use, typically casual, of pg_ctl without
> "-l" or similar.

Well, use as casual as that would probably also involve default logging
parameters, so that no switch will occur and thus this patch would print
nothing new.

I think that the vast majority of users who have nondefault logging
parameters have them because they're using some packaged version of
Postgres, and most of those are probably not using pg_ctl directly
at all, but going through some initscript or equivalent to start PG.
(At least, that's the set of people that this patch is trying to
improve usability for.) Any initscript is going to be redirecting
initial stderr to someplace besides the terminal.

>> Does that ameliorate your concern, or do you still want it to be DEBUG1?

> I think of the "implicit sequence" messages we moved from NOTICE to DEBUG1
> somewhat recently. No doubt those messages had helped at times, but they
> didn't quite carry their weight at NOTICE. My gut prediction is that this
> will fall in that same utility range. But you make a valid point about noise
> in the startup log being easier to discount.

Well, we can certainly back off the messages' log level if we get
complaints. But I think the argument for this patch being useful
is a great deal stronger if it's allowed to operate by default.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Browne 2013-08-10 16:30:45 Re: killing pg_dump leaves backend process
Previous Message Tom Lane 2013-08-10 14:40:08 Re: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work