From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, 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-29 15:11:41 |
Message-ID: | 20190429151141.rhbw5eshpolllxr6@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-04-28 19:24:59 -0400, Tom Lane wrote:
> Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> > 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 ...
I think we should start by just removing all uses of long. There's
really no excuse for them today, and a lot of them are bugs waiting to
happen. And then either just add a comment to the coding style, or even
better a small script, to prevent them from being re-used.
> > 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.)
We read from larger files in a few places though. E.g. pg_dump. Most
places really just should use pgoff_t...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-04-29 15:23:13 | Re: Race conditions with checkpointer and shutdown |
Previous Message | Tom Lane | 2019-04-29 15:10:45 | Re: jsonpath |