Peter Geoghegan <pg@bowt.ie> writes:
> On Thu, Jul 22, 2021 at 10:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
> 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.
Well, what we really ought to be using is size_t (a/k/a Size), at least
for memory-space-related calculations. I don't have an opinion right
now about what logtape.c ought to use. I do agree that avoiding "long"
altogether would be a good ultimate goal.
In the short term though, the question is whether we want to regard this
hashagg issue as something we need a fix for in v13/v14. The fact that
it's Windows-only makes it slightly less pressing in my mind, but it's
still a regression that some people are going to hit.
regards, tom lane
