On Fri, Nov 1, 2019 at 1:19 PM Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Nov 1, 2019 at 3:15 PM Peter Geoghegan <pg@bowt.ie> wrote:
> > I don't think that those two things are equivalent at all. There may
> > even be workloads that will benefit when run on 32-bit hardware.
> > Having to palloc() and pfree() with 8 byte integers is probably very
> > slow.
>
> Yeah! I mean, users who are using only 4-byte or smaller pass-by-value
> quantities will be harmed, especially in cases where they are storing
> a lot of them at the same time (e.g. sorting) and especially if they
> double their space consumption and run out of their very limited
> supply of memory.
Apparently Linux has almost no upstream resources for testing 32-bit
x86, and it shows:
https://lwn.net/ml/oss-security/CALCETrW1z0gCLFJz-1Jwj_wcT3+axXkP_wOCxY8JkbSLzV80GA@mail.gmail.com/
I think that this kind of thing argues for minimizing the amount of
code that can only be tested on a small minority of the computers that
are in general use today. If no Postgres hacker regularly runs the
code, then its chances of having bugs are far higher. Having coverage
in the buildfarm certainly helps, but it's no substitute.
Sticking with the !USE_FLOAT8_BYVAL example, it's easy to imagine
somebody forgetting to add a !USE_FLOAT8_BYVAL block, that contains
the required pfree(). Now you have a memory leak that only affects a
small minority of platforms. How likely is it that buildfarm coverage
will help somebody detect that problem?
--
Peter Geoghegan