Re: [bug fix] pg_ctl always uses the same event source

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

In response to

Responses

Browse pgsql-hackers by date

  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