* From: Amit Kapila
> On Sun, Apr 13, 2014 at 5:59 PM, Christian Ullrich <chris@chrullrich.net>
> wrote:
> > There are some possible solutions:
> >
> > - pg_ctl could set an environment variable (unless it has to be
> > compatible with postmasters from different versions, and it does
> > not, does it?).
>
> Do you mean to say use some existing environment variable?
> Introducing an environment variable to solve this issue or infact using
> some existing environ variable doesn't seem to be the best way to pass
> such information.
I meant creating a new one, yes. If, say, PGSQL_BACKGROUND_JOB was set,
the postmaster etc. would ignore the events.
> > pg_ctl creates a named job object, and the postmaster has all the
> > information it needs to reconstruct the name, so it can check if it is
> > running inside that pg_ctl-created job.
>
> We are already creating one job object, so may be that itself can be
> used, but not sure if Job Objects are supported on all platforms on which
> postgres works.
I mentioned that in my earlier message; we cannot rely on having that job
object around. If the OS does not support them (not much of a problem
nowadays, I think; anything anyone is going to run the version this will
first be released in on is going to) or, more likely, if something uses
PostgreSQL as "embedded" database and starts it in a job of their own,
pg_ctl will not create its job object.
There may also be software out there that a) runs PostgreSQL in this way,
b) uses the console events to stop it again, and c) does that with or
without a separate job object. Hence, deciding based on the existence of
a job object would break backward compatibility in this case, assuming
it exists in reality.
> If you have to pass such information, then why don't pass some special
> flag in command to CreateProcess()?
Because I wanted to avoid introducing a command line option to tell the
postmaster who started it. If we cannot look at job objects, and an
environment variable is not an option either, then this looks like the
best remaining solution.
I will create a patch based on this approach.
> There is always a chance that we ignore the CTRL+C for some app which
> we don't intend if we solve the problem by passing some info, as some
> other app could also do so, but I think it should not be a big problem.
No. In fact, if whatever starts the postmaster does pass that flag, we
can safely assume that it did not do so just for fun.
--
Christian