On Thu, Jul 23, 2020 at 03:38:43PM -0400, Tom Lane wrote:
> I dug into this problem with access kindly provided by Mark Wong, and
> verified that indeed the zlib on that machine acts a bit differently
> from stock zlib. The problem we're facing turns out to be entirely
> unrelated to the patch at hand; it's the *compression* side that is
> misbehaving. After some digging in the code and reading the zlib.h
> API spec carefully, the answer is that compress_process() completely
> mishandles the situation where deflate() stops short of consuming all
> the input that's supplied. It resets the next_in pointer so that
> old data is reprocessed, rather than allowing the remaining unprocessed
> data to be processed.
Good catch. Thanks.
> Anyway, with that corrected, the SLES zlib still produces different
> output from stock zlib, and indeed seemingly is worse: the result
> is noticeably larger than what stock zlib produces. It does decompress
> back to the same thing, though, so this is a performance problem not
> a data corruption issue. That does mean that the proposed test case
> fails to exercise our empty-ending-block scenario with this version
> of zlib. I don't think we really care about that, though.
One simple method to test this code path would be to just decompress a
hardcoded bytea value that got weirdly compressed. I am not sure
either if that's worth the cycles, and I think that it would bloat the
test files a bit.
> I will go apply this fix, and then you can put back the fix for
> the originally-reported problem. I still like Horiguchi-san's
> fix better than what was committed, though.
Back into business for this issue.. And I have been able to work more
on a SLES15 box thanks to Mark, confirming that b9b6105 got rid of the
compression issue with the test of 9e10898, and that the previous
versions of the patches would take care of the issue for the
decompression now if compressed data was incorrectly shaped.
--
Michael