Hi, On Tue, Jan 09, 2024 at 08:00:00PM +0300, Alexander Lakhin wrote: > Michael, it definitely increases stability of the test (tens of iterations > with 20 tests in parallel performed successfully),
Thanks for testing! > although I've managed to > see another interesting failure (twice): > 13 # Failed test 'activeslot slot invalidation is logged with vacuum > on pg_class' > 13 # at t/035_standby_logical_decoding.pl line 227. > Looking at the attached log files and particularly 1/regress_log_035_standby_logical_decoding: " [11:05:28.118](13.993s) ok 24 - inactiveslot slot invalidation is logged with vacuum on pg_class [11:05:28.119](0.001s) not ok 25 - activeslot slot invalidation is logged with vacuum on pg_class " That seems weird, the inactive slot has been invalidated while the active one is not. While it takes a bit longer to invalidate an active slot, I don't think the test can move on until both are invalidated (then leading to the tests 24 and 25)). I can see the tests are very slow to run (13.993s for 24) but still don't get how 24 could succeed while 25 does not. Looking at 2/regress_log_035_standby_logical_decoding: " [13:41:02.076](20.279s) ok 23 - inactiveslot slot invalidation is logged with vacuum on pg_class [13:41:02.076](0.000s) not ok 24 - activeslot slot invalidation is logged with vacuum on pg_class " Same "weird" behavior but this time the tests numbering are not the same (23 and 24). That is even more weird as those tests should be the 24 and 25 ones. Would it be possible to also send the standby logs? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
