Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass i64 and f64 by reference on 32-bit systems #1686

Closed

Conversation

CoderPuppy
Copy link

Fixes #1685.

This determines whether to pass by value or by reference based on the size of usize, this should replicate the behavior of the USE_FLOAT8_BYVAL macro defined in pg_config_manual.h.

@workingjubilee
Copy link
Member

You need to change far more than this.

Copy link
Member

@workingjubilee workingjubilee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Requires tests that validate that pgrx works on a 32-bit system. There is zero point in merging something that breaks in a week because almost everyone who uses pgrx, especially the primary developers of it, does so on 64-bit systems and thus there is almost no testing on 32-bit systems.

@workingjubilee
Copy link
Member

workingjubilee commented Apr 29, 2024

I also kinda want to know exactly why you want to run a real-ass database on a 32-bit system, much less with custom extensions. Postgres does... many things... that assume that there's an entire gigabyte just lying around of addressable memory, which is often not true on 32-bit systems, or can only be true due to swap files paging in and out, which makes the process slow and inefficient.

@workingjubilee
Copy link
Member

I'm sorry, but I still can't merge this without adding a regression test for it. We're in the middle of a big change to the codebase that is going to plow right down the middle of these traits: they are not easy to use soundly in complex cases, and the codebase uses them as a bound for safe code in places where they do not assure soundness.

No matter how simple this change may seem, there are reasons I am asking for a test.

Even for this change, an example of how we have multiple locations that rely on this assumption is here:

// This branch is optimized away (because `N` is constant).
let datum = match N {
// for match with `Datum`, read through that directly to
// preserve provenance (may not be relevant but doesn't hurt).
1 => pg_sys::Datum::from(byval_read::<u8>(ptr)),
2 => pg_sys::Datum::from(byval_read::<u16>(ptr)),
4 => pg_sys::Datum::from(byval_read::<u32>(ptr)),
8 => pg_sys::Datum::from(byval_read::<u64>(ptr)),
_ => unreachable!("`N` must be 1, 2, 4, or 8 (got {N})"),
};

I don't want to merge this and then have people complain every five seconds that I broke their code due to ghosts, because they managed to get a bit farther even though it was really never adequately supported in the first place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Pass 64-bit types by reference on 32-bit platforms
2 participants