Em dom., 25 de jul. de 2021 às 15:53, Tom Lane <t...@sss.pgh.pa.us> escreveu:
> Ranier Vilela <ranier...@gmail.com> writes:
> > I think int64 is in most cases the counterpart of *long* on Windows.
>
> I'm not particularly on board with s/long/int64/g as a universal
> solution.
Sure, not a universal solution, I mean a start point.
When I look for a type that is signed and size 8 bytes in Windows, I only
see int64.
I think that most of these usages are concerned with
> memory sizes and would be better off as "size_t".
Ok, but let's not forget that size_t is unsigned.
We might need
> int64 in places where we're concerned with sums of memory usage
> across processes, or where the value needs to be allowed to be
> negative. So it'll take case-by-case analysis to do it right.
>
Sure.
> BTW, one aspect of this that I'm unsure how to tackle is the
> common usage of "L" constants; in particular, "work_mem * 1024L"
> is a really common idiom that we'll need to get rid of. Not sure
> that grep will be a useful aid for finding those.
>
I can see 30 matches in the head tree. (grep -d "1024L" *.c)
File backend\access\gin\ginfast.c:
if (metadata->nPendingPages * GIN_PAGE_FREESIZE > cleanupSize *
1024L)
(accum.allocatedMemory >= workMemory * 1024L)))
Is it a good point to start?
or one more simple?
(src/backend/access/hash/hash.c) has one *long*.
regards,
Ranier Vilela
