Re: "long" type is not appropriate for counting tuples - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: "long" type is not appropriate for counting tuples
Date
Msg-id CAH2-Wzk8NPG49VhZqBAmFoChF52ekQQORCPmVgLBovJSxx9f5g@mail.gmail.com
Whole thread Raw
In response to Re: "long" type is not appropriate for counting tuples  (Andres Freund <andres@anarazel.de>)
Responses Re: "long" type is not appropriate for counting tuples
Re: "long" type is not appropriate for counting tuples
List pgsql-hackers
On Mon, Apr 29, 2019 at 8:11 AM Andres Freund <andres@anarazel.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Race conditions with checkpointer and shutdown
Next
From: Ashwin Agrawal
Date:
Subject: Re: Race conditions with checkpointer and shutdown