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
Thread:
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
not.

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

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

In response to

Responses

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