From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | MauMau <maumau307(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [bug fix] pg_ctl always uses the same event source |
Date: | 2014-04-05 14:54:31 |
Message-ID: | 13783.1396709671@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-04-05 15:05:09 | Re: Windows exit code 128 ... it's baaack |
Previous Message | Maxence Ahlouche | 2014-04-05 14:14:28 | GSoC 2014: Implementing clustering algorithms in MADlib |