Re: "long" type is not appropriate for counting tuples

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 17:16:39
Message-ID: CAH2-Wzk8NPG49VhZqBAmFoChF52ekQQORCPmVgLBovJSxx9f5g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 29, 2019 at 8:11 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> 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.

I like the idea of banning "long" altogether. It will probably be hard
to keep it out of third party code that we vendor-in, or even code
that interfaces with libraries in some way, but it should be removed
from everything else. It actually doesn't seem particularly hard to do
so, based on a quick grep of src/backend/. Most uses of "long" is code
that sizes something in local memory, where "long" works for the same
reason as it works when calculating the size of a work_mem allocation
-- ugly, but correct. A few uses of "long" seem to be real live bugs,
albeit bugs that are very unlikely to ever hit.

_h_indexbuild() has the same bug as _bt_load(), also due to commit
ab0dfc961b6 -- I spotted that in passing when I used grep.

> We read from larger files in a few places though. E.g. pg_dump. Most
> places really just should use pgoff_t...

I wasn't even aware of pgoff_t. It is only used in frontend utilities
that I don't know that much about, whereas off_t is used all over the
backend code.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashwin Agrawal 2019-04-29 17:26:09 Re: Race conditions with checkpointer and shutdown
Previous Message Andres Freund 2019-04-29 17:04:30 Re: Race conditions with checkpointer and shutdown