pgsql: Fix potential stack overflow in incremental backup.
Fix potential stack overflow in incremental backup.
The user can set RELSEG_SIZE to a high number at compile time, so we
can't use it to control the size of an array on the stack: it could be
many gigabytes in size. On closer inspection, we don't really need that
intermediate array anyway. Let's just write directly into the output
array, and then perform the absolute->relative adjustment in place.
This fixes new code from commit dc212340058.
Reviewed-by: Robert Haas <robertmhaas@gmail.com>
Discussion: /messages/by-id/CA+hUKG+2hZ0sBztPW4mkLfng0qfkNtAHFUfxOMLizJ0BPmi5+g@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/d8f5acbdb9b22106db583e3cbb177d34e6b18eeb
Modified Files
--------------
src/backend/backup/basebackup_incremental.c | 26 +++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)
Hi Thomas,
On Thu, Apr 11, 2024 at 01:53:24AM +0000, Thomas Munro wrote:
Fix potential stack overflow in incremental backup.
The user can set RELSEG_SIZE to a high number at compile time, so we
can't use it to control the size of an array on the stack: it could be
many gigabytes in size. On closer inspection, we don't really need that
intermediate array anyway. Let's just write directly into the output
array, and then perform the absolute->relative adjustment in place.
This fixes new code from commit dc212340058.
+ * file just as if this were not an incremental backup. The contents of the
+ * relative_block_numbers array is unspecified in this case. Perhaps you mean s/is/are/ here? The contents are what's not
specified.
--
Michael
On Thu, Apr 11, 2024 at 2:28 PM Michael Paquier <michael@paquier.xyz> wrote:
+ * file just as if this were not an incremental backup. The contents of the + * relative_block_numbers array is unspecified in this case.Perhaps you mean s/is/are/ here? The contents are what's not
specified.
Thanks, fixed. Duh.