fixing a few backup compression goofs

On Wed, Mar 23, 2022 at 5:52 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> I think you should also test the return value when setting the compress level.
> Not only because it's generally a good idea, but also because I suggested to
> support negative compression levels. Which weren't allowed before v1.3.4, and
> then the range is only defined since 1.3.6 (ZSTD_minCLevel). At some point,
> the range may have been -7..22 but now it's -131072..22.

Hi,

The attached patch fixes a few goofs around backup compression. It
adds a check that setting the compression level succeeds, although it
does not allow the broader range of compression levels Justin notes
above. That can be done separately, I guess, if we want to do it. It
also fixes the problem that client and server-side zstd compression
don't actually compress equally well; that turned out to be a bug in
the handling of compression options. Finally it adds an exit call to
an unlikely failure case so that we would, if that case should occur,
print a message and exit, rather than the current behavior of printing
a message and then dereferencing a null pointer.

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