pg.ddx.io  pgsql-committers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-committers@lists.postgresql.org
Subject: pgsql: Get rid of our dependency on type "long" for memory size calcula
Date: Fri, 31 Jan 2025 18:52:52 +0000
Message-ID: <E1tdw8K-004fdx-Jp@gemulon.postgresql.org> (raw)

Get rid of our dependency on type "long" for memory size calculations.

Consistently use "Size" (or size_t, or in some places int64 or double)
as the type for variables holding memory allocation sizes.  In most
places variables' data types were fine already, but we had an ancient
habit of computing bytes from kilobytes-units GUCs with code like
"work_mem * 1024L".  That risks overflow on Win64 where they did not
make "long" as wide as "size_t".  We worked around that by restricting
such GUCs' ranges, so you couldn't set work_mem et al higher than 2GB
on Win64.  This patch removes that restriction, after replacing such
calculations with "work_mem * (Size) 1024" or variants of that.

It should be noted that this patch was constructed by searching
outwards from the GUCs that have MAX_KILOBYTES as upper limit.
So I can't positively guarantee there are no other places doing
memory-size arithmetic in int or long variables.  I do however feel
pretty confident that increasing MAX_KILOBYTES on Win64 is safe now.
Also, nothing in our code should be dealing in multiple-gigabyte
allocations without authorization from a relevant GUC, so it seems
pretty likely that this search caught everything that could be at
risk of overflow.

Author: Vladlen Popolitov <v.popolitov@postgrespro.ru>
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/1a01f0-66ec2d80-3b-68487680@27595217

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/041e8b95b8cd251bfec6a3c9c3dd6614de6a4c9b

Modified Files
--------------
src/backend/access/gin/ginfast.c                     |  8 ++++----
src/backend/access/gin/ginget.c                      |  2 +-
src/backend/access/gin/gininsert.c                   |  2 +-
src/backend/access/hash/hash.c                       |  6 +++---
src/backend/access/heap/vacuumlazy.c                 |  4 ++--
src/backend/access/nbtree/nbtpage.c                  |  9 +++++----
src/backend/commands/vacuumparallel.c                |  2 +-
src/backend/executor/execUtils.c                     |  2 +-
src/backend/executor/nodeBitmapIndexscan.c           |  2 +-
src/backend/executor/nodeBitmapOr.c                  |  2 +-
src/backend/nodes/tidbitmap.c                        | 12 ++++++------
src/backend/optimizer/path/costsize.c                | 14 +++++++-------
src/backend/optimizer/plan/planner.c                 |  2 +-
src/backend/replication/logical/reorderbuffer.c      |  7 +++----
src/backend/utils/sort/tuplestore.c                  |  2 +-
src/include/executor/hashjoin.h                      |  2 +-
src/include/nodes/tidbitmap.h                        |  4 ++--
src/include/utils/dsa.h                              |  2 +-
src/include/utils/guc.h                              | 10 +++++++---
src/test/modules/test_bloomfilter/test_bloomfilter.c |  2 +-
20 files changed, 50 insertions(+), 46 deletions(-)



Message-ID: <E1tdw8K-004fdx-Jp@gemulon.postgresql.org>
Permalink:  ../E1tdw8K-004fdx-Jp@gemulon.postgresql.org/
Also on:    postgresql.org/message-id/E1tdw8K-004fdx-Jp@gemulon.postgresql.org

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-committers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, pgsql-committers@lists.postgresql.org
  Subject: Re: pgsql: Get rid of our dependency on type "long" for memory size calcula
  In-Reply-To: <E1tdw8K-004fdx-Jp@gemulon.postgresql.org>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox