On Tue, Jun 22, 2021 at 12:53:46PM +0900, Michael Paquier wrote: > > So the patches that you say are unrelated still seem to me to be a > > prerequisite . > > I may be missing something, of course, but I still don't see why > that's necessary? We don't get any test failures on HEAD by switching > wal_compression to on, no? That's easy enough to test with a two-line > change that changes the default.
Curious. I found that before a4d75c86bf, there was an issue without the "extra" patches. |commit a4d75c86bf15220df22de0a92c819ecef9db3849 |Author: Tomas Vondra <tomas.von...@postgresql.org> |Date: Fri Mar 26 23:22:01 2021 +0100 | | Extended statistics on expressions I have no idea why that patch changes the behavior, but before a4d7, this patch series failed like: |$ time time make -C src/test/recovery check ... |# Failed test 'new xid after restart is greater' |# at t/011_crash_recovery.pl line 53. |# '539' |# > |# '539' | |# Failed test 'xid is aborted after crash' |# at t/011_crash_recovery.pl line 57. |# got: 'committed' |# expected: 'aborted' |# Looks like you failed 2 tests of 3. |t/011_crash_recovery.pl .............. Dubious, test returned 2 (wstat 512, 0x200) |Failed 2/3 subtests I checked that my most recent WAL compression patch applied on top of a4d75c86bf works ok without the "extra" patches but fails when applied to a4d75c86bf~1. I think Andrey has been saying that since this already fails with PGLZ wal compression, we could consider this to be a pre-existing problem. I'm not thrilled with that interpretation, but it's not wrong. -- Justin