Fix incorrect calculation in BlockRefTableEntryGetBlocks.

The previous formula was incorrect in the case where the function's
nblocks argument was a multiple of BLOCKS_PER_CHUNK, which happens
whenever a relation segment file is exactly 512MB or exactly 1GB in
length. In such cases, the formula would calculate a stop_offset of
0 rather than 65536, resulting in modified blocks in the second half
of a 1GB file, or all the modified blocks in a 512MB file, being
omitted from the incremental backup.

Reported off-list by Tomas Vondra and Jakub Wartak.

Discussion: http://postgr.es/m/CA+TgmoYwy_KHp1-5GYNmVa=zdeJWhNH1T0SBmEuvqQNJEHj1Lw@mail.gmail.com

diff --git a/src/common/blkreftable.c b/src/common/blkreftable.c
index bfa6f7ab5d8d7809b7806f55a1a6ddc10e798f46..845b5d1dc46ed2cf07d583212ad4e4a09163b9fe 100644 (file)
--- a/src/common/blkreftable.c
+++ b/src/common/blkreftable.c
@@ -410,7 +410,11 @@ BlockRefTableEntryGetBlocks(BlockRefTableEntry *entry,
        if (chunkno == start_chunkno)
            start_offset = start_blkno % BLOCKS_PER_CHUNK;
        if (chunkno == stop_chunkno - 1)
-           stop_offset = stop_blkno % BLOCKS_PER_CHUNK;
+       {
+           Assert(stop_blkno > chunkno * BLOCKS_PER_CHUNK);
+           stop_offset = stop_blkno - (chunkno * BLOCKS_PER_CHUNK);
+           Assert(stop_offset <= BLOCKS_PER_CHUNK);
+       }
 
        /*
         * Handling differs depending on whether this is an array of offsets