longs where uint64s could be

On Fri, Jan 17, 2020 at 4:42 PM David Fetter <david@fetter.org> wrote:

While going over places where I might use compiler intrinsics for
things like ceil(log2(n))) and next power of 2(n), I noticed that a
lot of things that can't be fractional are longs instead of, say,
uint64s. Is this the case for historical reasons, or is there some
more specific utility to expressing as longs things that can only have
non-negative integer values? Did this practice pre-date our
now-required 64-bit integers?

Yeah, it's historic. I wince when I see "long" integers. They're
almost wrong by definition. Windows has longs that are only 32-bits
wide/the same width as a regular "int". Anybody that uses a long must
have done so because they expect it to be wider than an int, even
though in general it cannot be assumed to be in Postgres C code.

work_mem calculations often use long by convention. We restrict the
size of work_mem on Windows in order to make this safe everywhere. I
believe that this is based on a tacit assumption that long is wider
outside of Windows.

logtape.c uses long ints. This means that Windows cannot support very
large external sorts. I don't recall hearing any complaints about
that, but it still doesn't seem great.

--
Peter Geoghegan

On Fri, Jan 17, 2020 at 05:12:20PM -0800, Peter Geoghegan wrote:

On Fri, Jan 17, 2020 at 4:42 PM David Fetter <david@fetter.org> wrote:

While going over places where I might use compiler intrinsics for
things like ceil(log2(n))) and next power of 2(n), I noticed that a
lot of things that can't be fractional are longs instead of, say,
uint64s. Is this the case for historical reasons, or is there some
more specific utility to expressing as longs things that can only have
non-negative integer values? Did this practice pre-date our
now-required 64-bit integers?

Yeah, it's historic. I wince when I see "long" integers. They're
almost wrong by definition. Windows has longs that are only 32-bits
wide/the same width as a regular "int". Anybody that uses a long must
have done so because they expect it to be wider than an int, even
though in general it cannot be assumed to be in Postgres C code.

work_mem calculations often use long by convention. We restrict the
size of work_mem on Windows in order to make this safe everywhere. I
believe that this is based on a tacit assumption that long is wider
outside of Windows.

logtape.c uses long ints. This means that Windows cannot support very
large external sorts. I don't recall hearing any complaints about
that, but it still doesn't seem great.

Please find attached a patch that changes logtape.c and things in near
dependency to it that changes longs to appropriate ints.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate