| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
| 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>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Removing "long int"-related limit on hash table sizes |
| Date: | 2021-07-25 18:53:16 |
| Message-ID: | 173245.1627239196@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Ranier Vilela <ranier(dot)vf(at)gmail(dot)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. I think that most of these usages are concerned with
memory sizes and would be better off as "size_t". 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.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bryn Llewellyn | 2021-07-25 18:56:54 | Re: Have I found an interval arithmetic bug? |
| Previous Message | Justin Pryzby | 2021-07-25 17:56:54 | Re: when the startup process doesn't (logging startup delays) |