Thank you for reviewing and testing the patch.

>+       /* leave if data cannot be compressed */
>+       if (compressed_len == 0)
>+               return false;
>This should be < 0, pglz_compress returns -1 when compression fails.
>+               if (pglz_decompress(block_image, bkpb->bkp_len, 
>bkpb->bkp_uncompress_len) == 0)
>Similarly, this should be < 0.

These have been corrected in the attached.

>Regarding the sanity checks that have been added recently. I think that they 
>are useful but I am suspecting as well that only a check on the record CRC is 
>done because that's reliable enough and not doing those checks accelerates a 
>bit replay. So I am thinking that we should simply replace >them by assertions.
Removing the checks makes sense as CRC ensures correctness . Moreover ,as error 
message for invalid length of record is present in the code , messages for 
invalid block length can be redundant.
Checks have been replaced by assertions in the attached patch.

Following if  condition in XLogCompressBackupBlock has been modified as follows

+          * We recheck the actual size even if pglz_compress() reports success 
+          * see if at least 2 bytes of length have been saved, as this 
+          * to the additional amount of data stored in WAL record for a 
+          * block via raw_length when block contains hole..
+          */
+          *len = (uint16) compressed_len;
+          if (*len >= orig_len - SizeOfXLogRecordBlockImageCompressionInfo)
+                      return false;
+          return true;

if ((hole_length != 0) &&
+                      (*len >= orig_len - 
+          return false;
+return true

This is because the extra information raw_length is included only if compressed 
block has hole in it.

>Once we get those small issues fixes, I think that it is with having a 
>committer look at this patch, presumably Fujii-san
Agree. I will mark this patch as ready for committer

Thank you,
Rahila Syed

Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

Attachment: Support-compression-for-full-page-writes-in-WAL_v19.patch
Description: Support-compression-for-full-page-writes-in-WAL_v19.patch

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to