Re: Different compression methods for FPI

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