Hello.
On Wed, Jul 24, 2019 at 2:31 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> On 2019-Jul-23, Tom Lane wrote:
>
> > Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
>
> > > My investigation convinced me that there is no way for a process
> > > to detect wheter it is running as a service (except the process
> > > directly called from system (aka entry function)).
>
> Maybe we can try calling pgwin32_is_service()?
Ah, it might be viable. (I'm not sure though.) I didn't thought that
some process property we are enforcing is available.
> > But I will say that in my experience, behavioral differences between
> > Postgres started manually and Postgres started as a daemon are bad.
> > So I think going out of our way to make the cases behave differently
> > on Windows is probably not a good plan.
>
> We already have such a difference in Windows -- elog.c uses it
> extensively to use the eventlog to print if a service, console print if
> not.
>
> Given this thread's OP, ISTM failing to do likewise for this case makes
> debugging problems difficult for no good reason.
The difference of internal behavior is added to unify the external
(apparenet) behavior. It prevents WER dialog from showing while
running on console. Service doesn't show a dialog even if WER is
enabled. The remaining issue is we cannot obtain a dump when running
on console without being blocked by a dialog, but Windows just doesn't
allow it.. (Might be possible if we ignore Windows 7? 8? and earlier)
reagards
--
Kyotaro Horiguchi
NTT Open Source Software Center