Re: [bug fix] Produce a crash dump before main() on Windows

On 2019-Jul-24, Kyotaro Horiguchi wrote:

> Hello.
>
> On Wed, Jul 24, 2019 at 2:31 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> >
> > On 2019-Jul-23, Tom Lane wrote:
> >
> > > Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)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.

Well, ereport() relies on this pretty extensively, so it seems okay to
rely on it for this too.

> 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.

Yeah, that seems to be what we want (namely, not to get the server
process blocked waiting for the user to click on the dialog box).

> 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)

I don't know what a "dump" is in this context, but in the errbacktrace
thread I linked to a Stackoverflow question where they mentioned the API
to obtain a stack backtrace for a process in Windows. Maybe logging
that much info is sufficient for most cases.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services