Re: Different compression methods for FPI

On Sat, Mar 06, 2021 at 12:29:14PM +0500, Andrey Borodin wrote:
> > 1 марта 2021 г., в 10:03, Justin Pryzby <pryzby(at)telsasoft(dot)com> написал(а):
>
> Justin, Michael, thanks for comments!
>
> As far as I understood TODO list for the patch looks as follows:

Your patch can be simplified some, and then the only ifdef are in two short
functions. Moving the compression calls to another function/file is hardly
worth it, and anyone that implements a generic compression API could refactor
easily, if it's a win. So I don't want to impose the burden on your small
patch of setting up the compression API for everyone else's patches. Since
this is non-streaming compression, the calls are trivial.

One advantage of a generic API is that it's a good place to handle things like
compression options, like zstd:9 or zstd:3,rsyncable (I am not suggesting this
syntax).

Today, I re-sent an Dillip's patch with a change to use pkg-config for liblz4,
and it now also compiles on mac, so I used those changes to configure.ac (using
pkg-config) and src/tools/msvc/Solution.pm, and changed HAVE_LIBLZ4 to USE_LZ4.

This also resolves conflict with 32fd2b57d7f64948e649fc205c43f007762ecaac.

wal_compression_method is PGC_SIGHUP, not SUSET.

I think that the COMPRESSION_ID should have a prefix like XLOG_* - but didn't
do it here.

Does this patch need to bump XLOG_PAGE_MAGIC ?

wal_compression_options: I made this conditional compilation, so the GUC
machinery rejects methods which aren't supported. That means that xloginsert
doesn't need to check for unsupported methods. sync_method_options also uses
conditional compilation, but a GUC "check" hook would be more friendly, since
it could distinguish between "not supported" and "valid":
|ERROR: invalid value for parameter "wal_compression_method": "lz4"

--
Justin