Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitd8f5acb

Browse files
committed
Fix potential stack overflow in incremental backup.
The user can set RELSEG_SIZE to a high number at compile time, so wecan't use it to control the size of an array on the stack: it could bemany gigabytes in size. On closer inspection, we don't really need thatintermediate array anyway. Let's just write directly into the outputarray, and then perform the absolute->relative adjustment in place.This fixes new code from commitdc21234.Reviewed-by: Robert Haas <robertmhaas@gmail.com>Discussion:https://postgr.es/m/CA%2BhUKG%2B2hZ0sBztPW4mkLfng0qfkNtAHFUfxOMLizJ0BPmi5%2Bg%40mail.gmail.com
1 parentf56a9de commitd8f5acb

File tree

1 file changed

+17
-9
lines changed

1 file changed

+17
-9
lines changed

‎src/backend/backup/basebackup_incremental.c

Lines changed: 17 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -726,7 +726,8 @@ GetIncrementalFilePath(Oid dboid, Oid spcoid, RelFileNumber relfilenumber,
726726
* How should we back up a particular file as part of an incremental backup?
727727
*
728728
* If the return value is BACK_UP_FILE_FULLY, caller should back up the whole
729-
* file just as if this were not an incremental backup.
729+
* file just as if this were not an incremental backup. The contents of the
730+
* relative_block_numbers array is unspecified in this case.
730731
*
731732
* If the return value is BACK_UP_FILE_INCREMENTALLY, caller should include
732733
* an incremental file in the backup instead of the entire file. On return,
@@ -745,7 +746,6 @@ GetFileBackupMethod(IncrementalBackupInfo *ib, const char *path,
745746
BlockNumber*relative_block_numbers,
746747
unsigned*truncation_block_length)
747748
{
748-
BlockNumberabsolute_block_numbers[RELSEG_SIZE];
749749
BlockNumberlimit_block;
750750
BlockNumberstart_blkno;
751751
BlockNumberstop_blkno;
@@ -872,8 +872,13 @@ GetFileBackupMethod(IncrementalBackupInfo *ib, const char *path,
872872
errcode(ERRCODE_INTERNAL_ERROR),
873873
errmsg_internal("overflow computing block number bounds for segment %u with size %zu",
874874
segno,size));
875+
876+
/*
877+
* This will write *absolute* block numbers into the output array, but
878+
* we'll transpose them below.
879+
*/
875880
nblocks=BlockRefTableEntryGetBlocks(brtentry,start_blkno,stop_blkno,
876-
absolute_block_numbers,RELSEG_SIZE);
881+
relative_block_numbers,RELSEG_SIZE);
877882
Assert(nblocks <=RELSEG_SIZE);
878883

879884
/*
@@ -892,19 +897,22 @@ GetFileBackupMethod(IncrementalBackupInfo *ib, const char *path,
892897
returnBACK_UP_FILE_FULLY;
893898

894899
/*
895-
* Looks like we can send an incremental file, so sort theabsolute the
896-
*block numbersand then transpose absolute block numbers to relative
897-
*blocknumbers.
900+
* Looks like we can send an incremental file, so sort theblock numbers
901+
* and then transposethem fromabsolute block numbers to relative block
902+
* numbers if necessary.
898903
*
899904
* NB: If the block reference table was using the bitmap representation
900905
* for a given chunk, the block numbers in that chunk will already be
901906
* sorted, but when the array-of-offsets representation is used, we can
902907
* receive block numbers here out of order.
903908
*/
904-
qsort(absolute_block_numbers,nblocks,sizeof(BlockNumber),
909+
qsort(relative_block_numbers,nblocks,sizeof(BlockNumber),
905910
compare_block_numbers);
906-
for (i=0;i<nblocks;++i)
907-
relative_block_numbers[i]=absolute_block_numbers[i]-start_blkno;
911+
if (start_blkno!=0)
912+
{
913+
for (i=0;i<nblocks;++i)
914+
relative_block_numbers[i]-=start_blkno;
915+
}
908916
*num_blocks_required=nblocks;
909917

910918
/*

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp