Em qui., 22 de jul. de 2021 às 14:28, Peter Geoghegan <p...@bowt.ie> escreveu:
> On Thu, Jul 22, 2021 at 10:11 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > No, he already tried, upthread. The trouble is that he's on a Windows > > machine, so get_hash_mem is quasi-artificially constraining the product > > to 2GB. And he needs it to be a bit more than that. Whether the > > constraint is hitting at the ngroups stage or it's related to actual > > memory consumption isn't that relevant. > > Somehow I missed that part. > > > What I'm wondering about is whether it's worth putting in a solution > > for this issue in isolation, or whether we ought to embark on the > > long-ignored project of getting rid of use of "long" for any > > memory-size-related computations. There would be no chance of > > back-patching something like the latter into v13, though. > > +1. Even if we assume that Windows is a low priority platform, in the > long run it'll be easier to make it more like every other platform. > > The use of "long" is inherently suspect to me. It signals that the > programmer wants something wider than "int", even if the standard > doesn't actually require that "long" be wider. This seems to > contradict what we know to be true for Postgres, which is that in > general it's unsafe to assume that long is int64. It's not just > work_mem related calculations. There is also code like logtape.c, > which uses long for block numbers -- that also exposes us to risk on > Windows. > > By requiring int64 be used instead of long, we don't actually increase > risk for non-Windows platforms to any significant degree. I'm pretty > sure that "long" means int64 on non-Windows 64-bit platforms anyway. > I wonder if similar issues not raise from this [1]. (b/src/backend/optimizer/path/costsize.c) cost_tuplesort uses *long* to store sort_mem_bytes. I suggested switching to int64, but obviously to no avail. +1 to switch long to int64. regards, Ranier Vilela [1] https://www.postgresql.org/message-id/CAApHDvqhUYHYGmovoGWJQ1%2BZ%2B50Mz%3DPV6bW%3DQYEh3Z%2BwZTufPQ%40mail.gmail.com
