Add the missing loop exit condition based on Z_STREAM_END

[harukat]

doDeflate() function has no loop exit condition if deflate() returns Z_STREAM_END.
Therefore, this code could potentially cause an infinite loop.
Similar code using zlib in PostgreSQL has such an exit condition, so it would be desirable to do the same for pg_rman.

[atorik]

I don't have prior experience working directly with zlib, so I may be misunderstanding something.
If there is anything incorrect in my understanding, please feel free to point it out.

Based on my reading of zlib.h, it seems that deflate() returns Z_STREAM_END only when flush is set to Z_FINISH and all input has been fully processed:

 -- zlib-1.2.11/zlib.h
 326   If the parameter flush is set to Z_FINISH, pending input is processed,
 327   pending output is flushed and deflate returns with Z_STREAM_END if there was
 328   enough output space.

This suggests that a situation where zp->avail_in is non-zero while deflate() returns Z_STREAM_END should never occur.
If it does, it may indicate a bug in the zlib library itself.

If we want to explicitly handle this case, I think it would be more appropriate to add an assertion (e.g., Assert( status == Z_STREAM_END) when exiting the loop, following the example style from the official zlib site, rather than introducing a new condition to break the loop.

Here is the relevevant snippet from the site:

     /* compress until end of file */
     do {
     ...
         flush = feof(source) ? Z_FINISH : Z_NO_FLUSH;
     ...
         /* run deflate() on input until output buffer not full, finish
            compression if all of source has been read in */
         do {
     ...
             ret = deflate(&strm, flush);    /* no bad return value */
             }
         } while (strm.avail_out == 0);
         assert(strm.avail_in == 0);     /* all input will be used */

         /* done when last data in file processed */
     } while (flush != Z_FINISH);
     assert(ret == Z_STREAM_END);        /* stream will be complete *

[harukat]

I understand that this fix is not mandatory.
My proposed fix just mimics the following PostgreSQL codes.

• bin/pg_dump/compress_gzip.c: DeflateCompressorCommon()
• bin/pg_basebackup/walmethods.c: tar_write_compressed_data()

[atorik]

My proposed fix just mimics the following PostgreSQL codes.
Yes, but I'm wondering whether these PostgreSQL codes may not ideal.

As described earlier, I think deflate() only returns Z_STREAM_END when the flush parameter is set to Z_FINISH.
If that's the case, then checking whether the return value is Z_STREAM_END when flush is Z_NO_FLUSH would not make sense -- especially since Z_NO_FLUSH can be used repeatedly, while Z_STREAM_END is only expected at the very end of the stream.

Given that this logic is used during backup, where disk I/O is typically the bottleneck, the cost of this kind of check might not be a real concern in practice. However, it may be better not to have things we don't need.

Also, I find it slightly worrying that under some edge cases -- say, if there's a bug in zlib and avail_in is not zero but deflate() exits the loop without an error -- we might end up with unexpected behavior.