Re: [bug fix] pg_ctl always uses the same event source
От | Tom Lane |
---|---|
Тема | Re: [bug fix] pg_ctl always uses the same event source |
Дата | |
Msg-id | 13783.1396709671@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [bug fix] pg_ctl always uses the same event source (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [bug fix] pg_ctl always uses the same event source
(Amit Kapila <amit.kapila16@gmail.com>)
Re: [bug fix] pg_ctl always uses the same event source (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
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. 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. > In that case, it will use Default Event Source name PostgreSQL which > is same what server also does in case it gets error before processing > of event source config. That analogy doesn't hold because (1) a server spends most of its time already up, so only a tiny fraction of its error traffic might go to the default event source, and (2) actually, pretty much *none* of a server's log traffic will go to the default event source if something else has been configured, because the default value of log_destination isn't "eventlog". There might be a small window where GUC has assigned log_destination but not yet event_source from postgresql.conf, but it's just about negligible. In contrast, a large fraction of pg_ctl's possible error traffic is concerned with early failures like can't-find-the-postgres-executable or can't-find-the-data-directory, either of which would foreclose any possibility of selecting an event source that matches the server. So basically, I think having pg_ctl try to do what this patch proposes is a bad idea. If there's anyone who actually cares about where pg_ctl logs to on Windows, what would make sense is to add a pg_ctl switch to specify what event_source name to use. That's still not perfect of course, but at least only command-line-parsing errors would come out before the setting could be adopted. regards, tom lane
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Maxence AhloucheДата:
Сообщение: GSoC 2014: Implementing clustering algorithms in MADlib