> On Apr 27, 2022, at 9:45 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> [ starting a new thread cuz the shared-stats one is way too long ]
>
> Andres Freund <and...@anarazel.de> writes:
>> Add minimal tests for recovery conflict handling.
>
> It's been kind of hidden by other buildfarm noise, but
> 031_recovery_conflict.pl is not as stable as it should be [1][2][3][4].
>
> Three of those failures look like
Interesting,
I have been getting failures on REL_14_STABLE:
t/012_subtransactions.pl ............. 11/12
# Failed test 'Rollback of PGPROC_MAX_CACHED_SUBXIDS+ prepared transaction on
promoted standby'
# at t/012_subtransactions.pl line 211.
# got: '3'
# expected: '0'
t/012_subtransactions.pl ............. 12/12 # Looks like you failed 1 test of
12.
t/012_subtransactions.pl ............. Dubious, test returned 1 (wstat 256,
0x100)
Failed 1/12 subtests
And the logs, tmp_check/log/regress_log_012_subtransactions, showing:
### Enabling streaming replication for node "primary"
### Starting node "primary"
# Running: pg_ctl -D
/Users/mark.dilger/recovery_test/postgresql/src/test/recovery/tmp_check/t_012_subtransactions_primary_data/pgdata
-l
/Users/mark.dilger/recovery_test/postgresql/src/test/recovery/tmp_check/log/012_subtransactions_primary.log
-o --cluster-name=primary start
waiting for server to start.... done
server started
# Postmaster PID for node "primary" is 46270
psql:<stdin>:1: ERROR: prepared transaction with identifier "xact_012_1" does
not exist
not ok 11 - Rollback of PGPROC_MAX_CACHED_SUBXIDS+ prepared transaction on
promoted standby
# Failed test 'Rollback of PGPROC_MAX_CACHED_SUBXIDS+ prepared transaction on
promoted standby'
# at t/012_subtransactions.pl line 211.
# got: '3'
# expected: '0'
This is quite consistent for me, but only when I configure with
--enable-coverage and --enable-dtrace. (I haven't yet tried one of those
without the other.)
I wasn't going to report this yet, having not yet completely narrowed this
down, but I wonder if anybody else is seeing this?
I'll try again on master....
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
