On Sat, Apr 5, 2014 at 8:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapila16@gmail.com> writes:
>> Are you concerned about the case when user passes event_source name
>> in command line at the time of start:
>> pg_ctl start -o "-c event_source=PG9.4" -D <data_dir>
>
> Right.
>
>> If my understanding is right about your concern, then I think it will consider
>> the above case even when passed in command line. Example
>> postgres.exe -C event_source -c event_source=PG9.4 -D <data_dir>
>> PG9.4
>
> 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?
> It's conceivable that you could reverse-engineer it by looking at
> postmaster.opts as well as what -C mode has to say, and that'd likely work
> for the parameters pg_ctl cares about; but my goodness that's ugly and
> fragile. You'd basically be reimplementing a lot of GUC logic in pg_ctl.
>
> In any case, the real problem is that even if you trust the -C result to
> be right, by the time you've got this information there have already been
> a whole lot of opportunities for failures. It doesn't seem to me that
> having pg_ctl switch its error reporting target halfway through is really
> such a great idea.
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.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
