From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: "long" type is not appropriate for counting tuples |
Date: | 2019-04-28 23:24:59 |
Message-ID: | 10152.1556493899@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> Commit ab0dfc961b6 used a "long" variable within _bt_load() to count
> the number of tuples entered into a B-Tree index as it is built. This
> will not work as expected on Windows, even on 64-bit Windows, because
> "long" is only 32-bits wide.
Right. "long" used to be our convention years ago, but these days
tuple counts should be int64 or perhaps uint64. See e.g. 23a27b039.
> ISTM that we should try to come up with a way of making code like this
> work, rather than placing the burden on new code to get it right.
Other than "use the right datatype", I'm not sure what we can do?
In the meantime, somebody should fix ab0dfc961b6 ...
> Also, "off_t" is only 32-bits on Windows, which broke parallel CREATE
> INDEX (issued fixed by commit aa551830). I suppose that "off_t" is
> really a variant of the same problem.
Hmm, why is this a problem? We should only use off_t for actual file
access operations, and we don't use files greater than 1GB. (There's a
reason for that.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-04-28 23:49:43 | Re: "long" type is not appropriate for counting tuples |
Previous Message | Peter Geoghegan | 2019-04-28 22:30:39 | "long" type is not appropriate for counting tuples |