On Wed, Mar 23, 2022 at 5:52 PM Justin Pryzby <pry...@telsasoft.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
0001-Fix-a-few-goofs-in-new-backup-compression-code.patch
Description: Binary data
