Re: incorrect xlog.c coverage report

Alvaro Herrera writes: > I forgot to mention that this patch produces a new warning: > /pgsql/source/master/src/backend/tcop/postgres.c: In function 'quickdie': > /pgsql/source/master/src/backend/tcop/postgres.c:2737:2: warning: implicit > declaration of function '__gcov_flush'; did you mean

Re: incorrect xlog.c coverage report

On 2019-May-31, Alvaro Herrera wrote: > On 2019-May-30, Michael Paquier wrote: > > > On Wed, May 29, 2019 at 12:09:08PM -0400, Alvaro Herrera wrote: > > > Are there objections to doing that now on the master branch? > > > > Adding the flush call just on HEAD is fine for me. Not sure that > >

Re: incorrect xlog.c coverage report

On 2019-May-30, Michael Paquier wrote: > On Wed, May 29, 2019 at 12:09:08PM -0400, Alvaro Herrera wrote: > > Are there objections to doing that now on the master branch? > > Adding the flush call just on HEAD is fine for me. Not sure that > there is an actual reason to back-patch that. Okay

Re: incorrect xlog.c coverage report

On Wed, May 29, 2019 at 12:09:08PM -0400, Alvaro Herrera wrote: > Are there objections to doing that now on the master branch? Adding the flush call just on HEAD is fine for me. Not sure that there is an actual reason to back-patch that. -- Michael signature.asc Description: PGP signature

Re: incorrect xlog.c coverage report

On 2018-Nov-22, Michael Paquier wrote: > On Thu, Nov 22, 2018 at 10:56:39AM +0900, Masahiko Sawada wrote: > > On Thu, Nov 22, 2018 at 10:43 AM Thomas Munro > > wrote: > >> Presumably you could add your own call to __gcov_flush() in > >> quickdie(), so that we get GCOV data but no other

Re: incorrect xlog.c coverage report

On 2018-11-21 23:45:01 -0300, Alvaro Herrera wrote: > On 2018-Nov-22, Michael Paquier wrote: > > > On Thu, Nov 22, 2018 at 10:56:39AM +0900, Masahiko Sawada wrote: > > > On Thu, Nov 22, 2018 at 10:43 AM Thomas Munro > > > wrote: > > >> Presumably you could add your own call to __gcov_flush() in

Re: incorrect xlog.c coverage report

On 2018-Nov-22, Michael Paquier wrote: > On Thu, Nov 22, 2018 at 10:56:39AM +0900, Masahiko Sawada wrote: > > On Thu, Nov 22, 2018 at 10:43 AM Thomas Munro > > wrote: > >> Presumably you could add your own call to __gcov_flush() in > >> quickdie(), so that we get GCOV data but no other

Re: incorrect xlog.c coverage report

On Thu, Nov 22, 2018 at 10:56:39AM +0900, Masahiko Sawada wrote: > On Thu, Nov 22, 2018 at 10:43 AM Thomas Munro > wrote: >> Presumably you could add your own call to __gcov_flush() in >> quickdie(), so that we get GCOV data but no other atexit()-like stuff. >> I see that some people advocate

Re: incorrect xlog.c coverage report

On Thu, Nov 22, 2018 at 10:43 AM Thomas Munro wrote: > > On Thu, Nov 22, 2018 at 2:22 PM Michael Paquier wrote: > > On Wed, Nov 21, 2018 at 01:20:48PM -0500, Tom Lane wrote: > > > Alvaro Herrera writes: > > >> I think we should change all calls of ->teardown_node to ->stop(), > > >> except the

Re: incorrect xlog.c coverage report

On Thu, Nov 22, 2018 at 2:22 PM Michael Paquier wrote: > On Wed, Nov 21, 2018 at 01:20:48PM -0500, Tom Lane wrote: > > Alvaro Herrera writes: > >> I think we should change all calls of ->teardown_node to ->stop(), > >> except the one in the END block, and look for places which are currently > >>

Re: incorrect xlog.c coverage report

On Wed, Nov 21, 2018 at 01:20:48PM -0500, Tom Lane wrote: > Alvaro Herrera writes: >> I think we should change all calls of ->teardown_node to ->stop(), >> except the one in the END block, and look for places which are currently >> relying too much on END (i.e. add more ->stop() calls where

Re: incorrect xlog.c coverage report

Alvaro Herrera writes: > On 2018-Nov-21, Masahiko Sawada wrote: >> I've looked into this issue and this happens on my environment (CentOS >> 6.9 and gcob 4.4.7) as well. ISTM the cause would related to the >> immediate shutdown mode we're using in test_recovery_standby. Doh, of course. > I

Re: incorrect xlog.c coverage report

On 2018-Nov-21, Masahiko Sawada wrote: > I've looked into this issue and this happens on my environment (CentOS > 6.9 and gcob 4.4.7) as well. ISTM the cause would related to the > immediate shutdown mode we're using in test_recovery_standby. > Interestingly in my environment with the attached

Re: incorrect xlog.c coverage report

On Wed, Nov 21, 2018 at 12:50 AM Alvaro Herrera wrote: > > I noticed some strangeness in the test coverage reporting. For example, > in > https://coverage.postgresql.org/src/backend/access/transam/xlog.c.gcov.html > in the function readRecoveryCommandFile(), most of the branches parsing > the

Re: incorrect xlog.c coverage report

On 2018-Nov-20, Tom Lane wrote: > Alvaro Herrera writes: > > On 2018-Nov-20, Peter Eisentraut wrote: > >> I noticed some strangeness in the test coverage reporting. > > > Not sure what to make of this. > > What platform and compiler do you run the coverage build on? > > (I'm remembering that

Re: incorrect xlog.c coverage report

Alvaro Herrera writes: > On 2018-Nov-20, Peter Eisentraut wrote: >> I noticed some strangeness in the test coverage reporting. > Not sure what to make of this. What platform and compiler do you run the coverage build on? (I'm remembering that gcov was pretty nearly entirely broken on Fedora

Re: incorrect xlog.c coverage report

On 2018-Nov-20, Peter Eisentraut wrote: > I noticed some strangeness in the test coverage reporting. For example, > in > https://coverage.postgresql.org/src/backend/access/transam/xlog.c.gcov.html > in the function readRecoveryCommandFile(), most of the branches parsing > the individual recovery

incorrect xlog.c coverage report

I noticed some strangeness in the test coverage reporting. For example, in https://coverage.postgresql.org/src/backend/access/transam/xlog.c.gcov.html in the function readRecoveryCommandFile(), most of the branches parsing the individual recovery options (recovery_target_xid,