Re: Unstable tests for recovery conflict handling

> On Apr 27, 2022, at 10:11 AM, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>
> I'll try again on master....

Still with coverage and dtrace enabled, I get the same thing, except that master formats the logs a bit differently:

# Postmaster PID for node "primary" is 19797
psql:<stdin>:1: ERROR: prepared transaction with identifier "xact_012_1" does not exist
[10:26:16.314](1.215s) not ok 11 - Rollback of PGPROC_MAX_CACHED_SUBXIDS+ prepared transaction on promoted standby
[10:26:16.314](0.000s)
[10:26:16.314](0.000s) # Failed test 'Rollback of PGPROC_MAX_CACHED_SUBXIDS+ prepared transaction on promoted standby'
[10:26:16.314](0.000s) # at t/012_subtransactions.pl line 208.
[10:26:16.314](0.000s) # got: '3'
# expected: '0'

With coverage but not dtrace enabled, I still get the error, though the log leading up to the error now has a bunch of coverage noise lines like:

profiling: /Users/mark.dilger/recovery_test/postgresql/src/backend/utils/sort/tuplesort.gcda: cannot merge previous GCDA file: corrupt arc tag

The error itself looks the same except the timing numbers differ a little.

With neither enabled, all tests pass.

I'm inclined to think that either the recovery code or the test have a race condition, and that enabling coverage causes the race to come out differently. I'll keep poking....

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company