From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Removing "long int"-related limit on hash table sizes |
Date: | 2021-07-26 02:38:41 |
Message-ID: | YP4gMZL9dcDL7Z49@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jul 25, 2021 at 12:28:04PM -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> We really ought to just remove every single use of long.
>
> I have no objection to that as a long-term goal. But I'm not volunteering
> to do all the work, and in any case it wouldn't be a back-patchable fix.
> I feel that we do need to do something about this performance regression
> in v13.
Another idea may be to be more aggressive in c.h? A tweak there would
be dirtier than marking long as deprecated, but that would be less
invasive. Any of that is not backpatchable, of course..
> No, I don't like that. Using size_t for memory-size variables is good
> discipline. Moreover, I'm not convinced that even with 64-bit ints,
> overflow would be impossible in all the places I fixed here. They're
> multiplying several potentially very large values (one of which
> is a float). I think this is just plain sloppy coding, independently
> of which bit-width you choose to be sloppy in.
Yeah, using size_t where adapted is usually a good idea.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Nancarrow | 2021-07-26 02:47:50 | Re: Added schema level support for publication. |
Previous Message | Michael Paquier | 2021-07-26 02:13:14 | Re: Fix memory leak when output postgres_fdw's "Relations" |