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.vondra@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