Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: cf/5924~1
Choose a base ref
...
head repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: cf/5924
Choose a head ref
  • 4 commits
  • 31 files changed
  • 2 contributors

Commits on Aug 9, 2025

  1. Make type Datum be 8 bytes wide everywhere. 

    This still-WIP patch aims to make sizeof(Datum) be 8 on all
platforms including 32-bit ones.  The objective is to allow
USE_FLOAT8_BYVAL to be true everywhere, and in consequence to
remove a lot of code that is specific to pass-by-reference
handling of float8, int8, etc.  In this way we can reduce the
maintenance effort involved in supporting 32-bit platforms,
without going so far as to actually desupport them.  Since Datum
is strictly an in-memory concept, this has no impact on on-disk
storage, though an initdb or pg_upgrade will be needed to fix
affected pg_type.typbyval entries.

We can expect that this change will make 32-bit builds a bit slower
and more memory-hungry, although being able to use pass-by-value
handling of 8-byte types may buy back some of that.  But we stopped
optimizing for 32-bit cases a long time ago, and this seems like
just another step on that path.

This initial patch simply forces the correct type definition and
USE_FLOAT8_BYVAL setting, and cleans up a couple of minor compiler
complaints that ensued.  This is sufficient for testing purposes.
In the wake of a bunch of Datum-conversion cleanups by Peter
Eisentraut, this now compiles cleanly with gcc on a 32-bit platform.
(I'd only tested the previous version with clang, which it turns out
is less picky than gcc about width-changing coercions.)

If we pursue this path, we would of course want to remove all
the now-dead code (search for mentions of SIZEOF_DATUM and
USE_FLOAT8_BYVAL to find likely places to clean up).  I have
not bothered with that yet.  A more interesting question is
whether there are comments or calculations that need adjustment.
There is probably an effect on the largest array that we can
support in 32-bit mode, for example.

Discussion: https://postgr.es/m/[email protected]
    @tglsfdc
    tglsfdc authored and Commitfest Bot committed Aug 9, 2025
    Configuration menu
    Copy the full SHA
    a703f5e View commit details
    Browse the repository at this point in the history

  2. Grab the low-hanging fruit from forcing sizeof(Datum) to 8. 

    Remove conditionally-compiled code for smaller Datum widths.
I also fixed up a few more places that were not using
DatumGetIntXX where they should.

One thing I remembered while preparing this part is that SP-GiST
stores pass-by-value prefix keys as Datums, so that the on-disk
representation depends on sizeof(Datum).  That's even more
unfortunate than the existing commentary makes it out to be,
because now there is a hazard that the change of sizeof(Datum)
will break SP-GiST indexes on 32-bit machines.  It appears that
there are no existing SP-GiST opclasses that are actually
affected; and if there are some that I didn't find, the number
of installations that are using them on 32-bit machines is
doubtless tiny.  So I'm proceeding on the assumption that we
can get away with this, but it's something to worry about.

(gininsert.c looks like it has a similar problem, but it's okay
because the "tuples" it's constructing are just transient data
within the tuplesort step.  That's pretty poorly documented
though, so I added some comments.)

Discussion: https://postgr.es/m/[email protected]
    @tglsfdc
    tglsfdc authored and Commitfest Bot committed Aug 9, 2025
    Configuration menu
    Copy the full SHA
    fb6fac5 View commit details
    Browse the repository at this point in the history

  3. Grab the low-hanging fruit from forcing USE_FLOAT8_BYVAL to true. 

    Remove conditionally-compiled code for the other case.

I did not bother removing uses of the FLOAT8PASSBYVAL macro,
except for getting rid of it in pg_type.dat so that initdb can
skip the step of replacing it.  Other references could be
replaced with "true" but it would save nothing.

I also left the associated pg_control and Pg_magic_struct
fields in place.  Perhaps we should get rid of them, but
it would save little.

Discussion: https://postgr.es/m/[email protected]
    @tglsfdc
    tglsfdc authored and Commitfest Bot committed Aug 9, 2025
    Configuration menu
    Copy the full SHA
    8e64223 View commit details
    Browse the repository at this point in the history

  4. [CF 5924] v1 - Making type Datum be 8 bytes everywhere 

    This branch was automatically generated by a robot using patches from an
email thread registered at:

https://commitfest.postgresql.org/patch/5924

The branch will be overwritten each time a new patch version is posted to
the thread, and also periodically to check for bitrot caused by changes
on the master branch.

Patch(es): https://www.postgresql.org/message-id/[email protected]
Author(s): Tom Lane
    Commitfest Bot committed Aug 9, 2025
    Configuration menu
    Copy the full SHA
    aca62c3 View commit details
    Browse the repository at this point in the history
Loading