From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Alexander Lakhin <exclusion@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: gcov coverage data not full with immediate stop
In-reply-to: <20200511034243.GA5671@alvherre.pgsql>
References: <20200511034243.GA5671@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Sun, 10 May 2020 23:42:43 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28858.1589172997.1@sss.pgh.pa.us>
Date: Mon, 11 May 2020 00:56:37 -0400
Message-ID: <28859.1589172997@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2020-May-10, Alexander Lakhin wrote:
>> 3. Explicitly call __gcov_flush in SIGQUIT handler (quickdie)?

> I tried your idea 3 a long time ago and my experiments didn't show an
> increase in coverage [1].  But I like this idea the best, and maybe I
> did something wrong.  Attached is the patch I had (on top of
> fc115d0f9fc6), but I don't know if it still applies.

Putting ill-defined, not-controlled-by-us work into a quickdie signal
handler sounds like a really bad idea to me.  Maybe it's all right,
since presumably it would only appear in specialized test builds; but
even so, how much could you trust the results?

> I think we should definitely get this fixed for pg13 ...

-1 for shoving in such a thing so late in the cycle.  We've survived
without it for years, we can do so for a few months more.

			regards, tom lane