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

Commit1e25cdb

Browse files
committed
Avoid integer overflow while testing wal_skip_threshold condition.
smgrDoPendingSyncs had two distinct risks of integer overflow whiledeciding which way to ensure durability of a newly-created relation.First, it accumulated the total size of all forks in a variable oftype BlockNumber (uint32). While we restrict an individual fork'ssize to fit in that, I don't believe there's such a restriction onall of them added together. Second, it proceeded to multiply thesum by BLCKSZ, which most certainly could overflow a uint32.(The exact expression is total_blocks * BLCKSZ / 1024. Thecompiler might choose to optimize that to total_blocks * 8,which is not at quite as much risk of overflow as a literalreading would be, but it's still wrong.)If an overflow did occur it could lead to a poor choice toshove a very large relation into WAL instead of fsync'ing it.This wouldn't be fatal, but it could be inefficient.Change total_blocks to uint64 which should be plenty, andrearrange the comparison calculation to be overflow-safe.I noticed this while looking for ramifications of the proposedchange in MAX_KILOBYTES. It's not entirely clear to me whywal_skip_threshold is limited to MAX_KILOBYTES in thefirst place, but in any case this code is unsafe regardlessof the range of wal_skip_threshold.Oversight inc6b9204 which introduced wal_skip_threshold,so back-patch to v13.Discussion:https://postgr.es/m/1a01f0-66ec2d80-3b-68487680@27595217Backpatch-through: 13
1 parent6e41e9e commit1e25cdb

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

‎src/backend/catalog/storage.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -763,7 +763,7 @@ smgrDoPendingSyncs(bool isCommit, bool isParallelWorker)
763763
{
764764
ForkNumberfork;
765765
BlockNumbernblocks[MAX_FORKNUM+1];
766-
BlockNumbertotal_blocks=0;
766+
uint64total_blocks=0;
767767
SMgrRelationsrel;
768768

769769
srel=smgropen(pendingsync->rlocator,INVALID_PROC_NUMBER);
@@ -807,7 +807,7 @@ smgrDoPendingSyncs(bool isCommit, bool isParallelWorker)
807807
* main fork is longer than ever but FSM fork gets shorter.
808808
*/
809809
if (pendingsync->is_truncated||
810-
total_blocks*BLCKSZ /1024>=wal_skip_threshold)
810+
total_blocks>=wal_skip_threshold* (uint64)1024/BLCKSZ)
811811
{
812812
/* allocate the initial array, or extend it, if needed */
813813
if (maxrels==0)

0 commit comments

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