| From: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
|---|---|
| To: | "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com> |
| Cc: | 'Kyotaro Horiguchi' <horikyota(dot)ntt(at)gmail(dot)com>, "masao(dot)fujii(at)oss(dot)nttdata(dot)com" <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, "david(at)pgmasters(dot)net" <david(at)pgmasters(dot)net>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "laurenz(dot)albe(at)cybertec(dot)at" <laurenz(dot)albe(at)cybertec(dot)at> |
| Subject: | RE: Stronger safeguard for archive recovery not to miss data |
| Date: | 2021-04-05 07:04:09 |
| Message-ID: | TYAPR01MB29908AB38962907EDDF29EA8FE779@TYAPR01MB2990.jpnprd01.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: osumi(dot)takamichi(at)fujitsu(dot)com <osumi(dot)takamichi(at)fujitsu(dot)com>
> By the way, when I build postgres with this patch and enable-coverage option,
> the results of RT becomes unstable. Does someone know the reason ?
> When it fails, I get stderr like below
>
> t/001_start_stop.pl .. 10/24
> # Failed test 'pg_ctl start: no stderr'
> # at t/001_start_stop.pl line 48.
> # got:
> 'profiling:/home/k5user/new_disk/recheck/PostgreSQL-Source-Dev/src/bac
> kend/executor/execMain.gcda:Merge mismatch for function 15
> # '
> # expected: ''
> t/001_start_stop.pl .. 24/24 # Looks like you failed 1 test of 24.
> t/001_start_stop.pl .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/24
> subtests
>
> Similar phenomena was observed in [1] and its solution seems to upgrade my
> gcc higher than 7. And, I did so but still get this unstable error with
> enable-coverage. This didn't happen when I remove enable-option and the
> make check-world passes.
Can you share the steps you took? e.g.,
$ configure --enable-coverage ...
$ make world
$ make check-world
$ patch -p1 < your_patch
$ make world
$ make check-world
A bit of Googling shows that the same error message has shown up in the tests of other software than Postgres. It doesn't seem like this failure is due to your patch.
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2021-04-05 07:06:07 | Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput? |
| Previous Message | Jaime Casanova | 2021-04-05 06:31:17 | use AV worker items infrastructure for GIN pending list's cleanup |