Re: refactoring basebackup.c (zstd)

On Tue, Feb 15, 2022 at 12:59 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> There's superfluous changes to ./configure unrelated to the changes in
> configure.ac. Probably because you're using a different version of autotools,
> or a vendor's patched copy. You can remove the changes with git checkout -p or
> similar.

I noticed this already and fixed it in the version of the patch I
posted on the other thread.

> +++ b/src/backend/replication/basebackup_zstd.c
> +bbsink *
> +bbsink_zstd_new(bbsink *next, int compresslevel)
> +{
> +#ifndef HAVE_LIBZSTD
> + ereport(ERROR,
> + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> + errmsg("zstd compression is not supported by this build")));
> +#else
>
> This should have an return; like what's added by 71cbbbbe8 and 302612a6c.
> Also, the parens() around errcode aren't needed since last year.

The parens are still acceptable style, though. The return I guess is needed.

> + bbsink_zstd *sink;
> +
> + Assert(next != NULL);
> + Assert(compresslevel >= 0 && compresslevel <= 22);
> +
> + if (compresslevel < 0 || compresslevel > 22)
> + ereport(ERROR,
>
> This looks like dead code in assert builds.
> If it's unreachable, it can be elog().

Actually, the right thing to do here is remove the assert, I think. I
don't believe that the code is unreachable. If I'm wrong and it is
unreachable then the test-and-ereport should be removed.

> + * Compress the input data to the output buffer until we run out of input
> + * data. Each time the output buffer falls below the compression bound for
> + * the input buffer, invoke the archive_contents() method for then next sink.
>
> *the next sink ?

Yeah.

> Does anyone plan to include this for pg15 ? If so, I think at least the WAL
> compression should have support added too. I'd plan to rebase Michael's patch.
> https://www.postgresql.org/message-id/YNqWd2GSMrnqWIfx@paquier.xyz

Yes, I'd like to get this into PG15. It's very similar to the LZ4
compression support which was already committed, so it feels like
finishing it up and including it in the release makes a lot of sense.
I'm not against the idea of using ZSTD in other places where it makes
sense as well, but I think that's a separate issue from this patch. As
far as I'm concerned, either basebackup compression with ZSTD or WAL
compression with ZSTD could be committed even if the other is not, and
I plan to spend my time on this project, not that project. However, if
you're saying you want to work on the WAL compression stuff, I've got
no objection to that.

--
Robert Haas
EDB: http://www.enterprisedb.com