Amit Kapila <amit.kapila16@gmail.com> writes:
> On Sat, Apr 5, 2014 at 8:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> How's that going to work during pg_ctl stop? There's no -o switch
>> provided.
> As there's no -o switch, so there won't be problem of getting wrong event
> source name from server due to command line options which you mentioned
> upthread or is there something which I am missing about it?
AFAICS, the sole argument for trying to do things this way is to log to
the same event_source the running postmaster is using. But -C will not
provide that; it will only tell you what the postmaster *would* use if
it were freshly started right now. If -o had been used at postmaster
start time, an inquiry done by pg_ctl stop (or reload, etc) won't match.
Another, possibly more plausible, failure mode is if the entry in
postgresql.conf has been edited since the running postmaster looked at it.
Admittedly, all of these cases are kind of unusual. But that's all the
more reason, IMO, to be wary of sending our error messages to an
unexpected place in such cases. Somebody who's trying to debug a
configuration problem doesn't need the added complication of trying to
figure out where pg_ctl's error messages might have gone.
> You are right that with the current patch approach, we will miss many
> opportunities for failures and the way suggested by you below (new switch)
> is more appropriate to fix this issue. Another thought that occurred to me
> is why not change the failures which are before set of appropriate
> event_source to report on console. The main reason for using event log
> to report error's in pg_ctl is because it can be used for service
> (register/unregister/..) in Windows and all the work we do before setting
> event_source is not related to it's usage as a service.
AFAICS, pg_ctl already reports to stderr if stderr is a tty. This whole
issue only comes up when pg_ctl itself is running as a service (which
I guess primarily means starting/stopping the postgresql service?).
So that puts extra weight on trying to be sure that error messages go
to a predictable place; the user's going to be hard-pressed to debug
background failures without that.
regards, tom lane