On Tue, May 12, 2020 at 10:10 AM Tom Lane wrote:
> > Can that easily be accommodated?
>
> There's no real lead time needed AFAICS: when we are ready to branch,
> we can just do it. So sure, let's wait till the end of May to decide.
> If things look bad then, we could reconsider again mid-June.
G
On Mon, May 11, 2020 at 05:56:33PM +0530, Ashutosh Bapat wrote:
> What happens if a coverage tool other than gcov is used? From that
> perspective, it's better to perform a clean shutdown in the TAP tests
> instead of immediate if that's possible.
Nope, as that's the fastest path we have to shut d
Peter Geoghegan writes:
> On Mon, May 11, 2020 at 1:04 PM Tom Lane wrote:
>> Yeah. Traditionally we've waited till the start of the next commitfest
>> (which I'm assuming is July 1, for lack of an Ottawa dev meeting to decide
>> differently). But it seems like things are slow enough that perhap
On Mon, May 11, 2020 at 1:04 PM Tom Lane wrote:
> Yeah. Traditionally we've waited till the start of the next commitfest
> (which I'm assuming is July 1, for lack of an Ottawa dev meeting to decide
> differently). But it seems like things are slow enough that perhaps
> we could branch earlier, l
On Mon, May 11, 2020 at 4:04 PM Tom Lane wrote:
> This is the wrong thread to be debating that in, though.
True.
> Also I wonder if this is really RMT turf?
I think it is, but the RMT is permitted -- even encouraged -- to
consider the views of non-RMT members when making its decision.
--
Robe
Robert Haas writes:
> I agree, but also, we should start thinking about when to branch. I,
> too, have patches that aren't critical enough to justify pushing them
> post-freeze, but which are still good improvements that I'd like to
> get into the tree. I'm queueing them right now to avoid the ris
On Mon, May 11, 2020 at 12:56 AM Tom Lane wrote:
> > 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.
I agree, but also, we should start thinking about when
On Mon, May 11, 2020 at 2:30 PM Alexander Lakhin wrote:
>
> But I can confirm that calling __gcov_flush() in SignalHandlerForCrashExit()
> really improves a code coverage report.
>
> Finally I've managed to get an expected coverage when I performed
> $node_standby->stop() (but __gcov_flush() in
Hello Alvaro,
11.05.2020 06:42, Alvaro Herrera wrote:
> (Strangely, I was just thinking about these branches of mine as I
> closed my week last Friday...)
>
> On 2020-May-10, Alexander Lakhin wrote:
>
>> So if we want to make the coverage reports more precise, I see the three
>> ways:
>> 1. Change
Alvaro Herrera 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.
(Strangely, I was just thinking about these branches of mine as I
closed my week last Friday...)
On 2020-May-10, Alexander Lakhin wrote:
> So if we want to make the coverage reports more precise, I see the three
> ways:
> 1. Change the stop mode in teardown_node to fast (probably only when
> conf
Hello hackers,
I've found that gcov coverage data miss some information when a postgres
node stopped in 'immediate' mode.
For example, on the master branch:
make coverage-clean; time make check -C src/test/recovery/; make
coverage-html
generates a coverage report with 106193 lines/6318 functions f
12 matches
Mail list logo
