Re: Proposal: leave a hint when switching logging away from stderr - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal: leave a hint when switching logging away from stderr
Date
Msg-id 14412.1376146676@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal: leave a hint when switching logging away from stderr  (Noah Misch <noah@leadboat.com>)
Responses Re: Proposal: leave a hint when switching logging away from stderr  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work
Next
From: Christopher Browne
Date:
Subject: Re: killing pg_dump leaves backend process