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 'pq
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
> > th
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 ...
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
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 atexit()-
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
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 atexit()-
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 doi
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 o
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
> >>
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 needed
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 think
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 one
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 ind
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 g
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 awh
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
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,
recovery_target_time,
18 matches
Mail list logo
