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