Amit Kapila <amit.kapil...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
