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

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com, amit(dot)kapila16(at)gmail(dot)com, kommi(dot)haribabu(at)gmail(dot)com, michael(at)paquier(dot)xyz, robertmhaas(at)gmail(dot)com, craig(at)2ndquadrant(dot)com, magnus(at)hagander(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [bug fix] Produce a crash dump before main() on Windows
Date: 2019-07-23 17:31:53
Message-ID: 20190723173153.GA12835@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

> 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

Given this thread's OP, ISTM failing to do likewise for this case makes
debugging problems difficult for no good reason.

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2019-07-23 17:42:22 Re: stress test for parallel workers
Previous Message Tom Lane 2019-07-23 17:28:47 Re: stress test for parallel workers