pgrx Supporting PostgreSQL forks

Some users wish to use PGRX with "almost Postgres" databases: forks that are 90% conformant to how Postgres operates and its internal sources, but that deviate in some regard. These can hypothetically be supported, but will require external assistance to understand the deviations of the fork, as we are, broadly speaking, specialists in Postgres, not Greenplum and so on. It would be especially helpful to have assistance in running and troubleshooting CI for such a fork.

These databases likely will also have to be defined separately from the normal version features, e.g. not pg12 but greenplum7. Or perhaps two features, with both greenplum7 and pg12? Either way.

Example issues:

https://github.com/postgresml/postgresml/issues/780

Jun 24 '23 18:06 workingjubilee

I expect there are some broad changes that need to be done to enable PGRX to work with "not-Postgres" Postgres versions, but we can also expect more specific requirements for the one that initiated this issue.

Greenplum 7 Support Requirements

Specific problems that need to be addressed to enable compiling some PGRX-based extensions against Greenplum 7, based on this error message:

Compilation failure using Greenplum 7

error[E0425]: cannot find function `heap_copytuple` in crate `pg_sys`
     --> /home/gpadmin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pgrx-0.9.2/src/heap_tuple.rs:173:37
      |
173   |         let copy = unsafe { pg_sys::heap_copytuple(self.tuple.into_pg()) };
      |                                     ^^^^^^^^^^^^^^ help: a function with a similar name exists: `SPI_copytuple`
      |
     ::: /home/gpadmin/postgresml/pgml-extension/target/release/build/pgrx-pg-sys-94bba98004a0ff70/out/pg12.rs:44792:1
      |
44792 | #[pgrx_macros::pg_guard]
      | ------------------------ similarly named function `SPI_copytuple` defined here

error[E0425]: cannot find function `heap_form_tuple` in crate `pg_sys`
     --> /home/gpadmin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pgrx-0.9.2/src/heap_tuple.rs:228:29
      |
228   |                     pg_sys::heap_form_tuple(tuple_desc.as_ptr(), datums, is_null.as_mut_ptr());
      |                             ^^^^^^^^^^^^^^^ help: a function with a similar name exists: `heap_deform_tuple`
      |
     ::: /home/gpadmin/postgresml/pgml-extension/target/release/build/pgrx-pg-sys-94bba98004a0ff70/out/pg12.rs:18858:1
      |
18858 | #[pgrx_macros::pg_guard]
      | ------------------------ similarly named function `heap_deform_tuple` defined here

error[E0425]: cannot find function `heap_form_tuple` in crate `pg_sys`
     --> /home/gpadmin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pgrx-0.9.2/src/heap_tuple.rs:272:25
      |
272   |                 pg_sys::heap_form_tuple(tupdesc.as_ptr(), datums.as_mut_ptr(), nulls.as_mut_ptr());
      |                         ^^^^^^^^^^^^^^^ help: a function with a similar name exists: `heap_deform_tuple`
      |
     ::: /home/gpadmin/postgresml/pgml-extension/target/release/build/pgrx-pg-sys-94bba98004a0ff70/out/pg12.rs:18858:1
      |
18858 | #[pgrx_macros::pg_guard]
      | ------------------------ similarly named function `heap_deform_tuple` defined here

error[E0425]: cannot find function `heap_form_tuple` in crate `pg_sys`
     --> /home/gpadmin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pgrx-0.9.2/src/htup.rs:210:33
      |
210   |                         pg_sys::heap_form_tuple(tupdesc, datums.as_mut_ptr(), nulls.as_mut_ptr())
      |                                 ^^^^^^^^^^^^^^^ help: a function with a similar name exists: `heap_deform_tuple`
      |
     ::: /home/gpadmin/postgresml/pgml-extension/target/release/build/pgrx-pg-sys-94bba98004a0ff70/out/pg12.rs:18858:1
      |
18858 | #[pgrx_macros::pg_guard]
      | ------------------------ similarly named function `heap_deform_tuple` defined here

error[E0425]: cannot find function, tuple struct or tuple variant `MemoryContextDelete` in crate `pg_sys`
     --> /home/gpadmin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pgrx-0.9.2/src/memcxt.rs:189:21
      |
189   |             pg_sys::MemoryContextDelete(self.owned);
      |                     ^^^^^^^^^^^^^^^^^^^ help: a function with a similar name exists: `MemoryContextReset`
      |
     ::: /home/gpadmin/postgresml/pgml-extension/target/release/build/pgrx-pg-sys-94bba98004a0ff70/out/pg12.rs:26103:1
      |
26103 | #[pgrx_macros::pg_guard]
      | ------------------------ similarly named function `MemoryContextReset` defined here

error[E0425]: cannot find function, tuple struct or tuple variant `MemoryContextDelete` in crate `pg_sys`
     --> /home/gpadmin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pgrx-0.9.2/src/memcxt.rs:400:29
      |
400   |                     pg_sys::MemoryContextDelete(context);
      |                             ^^^^^^^^^^^^^^^^^^^ help: a function with a similar name exists: `MemoryContextReset`
      |
     ::: /home/gpadmin/postgresml/pgml-extension/target/release/build/pgrx-pg-sys-94bba98004a0ff70/out/pg12.rs:26103:1
      |
26103 | #[pgrx_macros::pg_guard]
      | ------------------------ similarly named function `MemoryContextReset` defined here

error[E0063]: missing field `bgw_start_rule` in initializer of `pgrx_pg_sys::BackgroundWorker`
   --> /home/gpadmin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pgrx-0.9.2/src/bgworkers.rs:574:19
    |
574 |         let bgw = pg_sys::BackgroundWorker {
    |                   ^^^^^^^^^^^^^^^^^^^^^^^^ missing `bgw_start_rule`

error[E0061]: this function takes 2 arguments but 0 arguments were supplied
     --> /home/gpadmin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pgrx-0.9.2/src/bgworkers.rs:603:9
      |
603   |         pg_sys::check_for_interrupts!();
      |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ two arguments of type `*const i8` and `i32` are missing
      |
note: function defined here
     --> /home/gpadmin/postgresml/pgml-extension/target/release/build/pgrx-pg-sys-94bba98004a0ff70/out/pg12.rs:18056:12
      |
18056 |     pub fn ProcessInterrupts(
      |            ^^^^^^^^^^^^^^^^^
      = note: this error originates in the macro `pg_sys::check_for_interrupts` (in Nightly builds, run with -Z macro-backtrace for more info)
help: provide the arguments
     -->   /home/gpadmin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pgrx-pg-sys-0.9.2/src/submodules/elog.rs:445:42
      |
445   |                 $crate::ProcessInterrupts(/* *const i8 */, /* i32 */);
      |                                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Some errors have detailed explanations: E0061, E0063, E0425.
For more information about an error, try `rustc --explain E0061`.
error: could not compile `pgrx` (lib) due to 8 previous errors
warning: build failed, waiting for other jobs to finish...

Greenplum 7 is based on PostgreSQL 12 and thus would normally use this header as the basis of our generated bindings: https://github.com/tcdi/pgrx/blob/master/pgrx-pg-sys/include/pg12.h and thus we must address that

[ ] heap_copytuple is not present in the included headers
[ ] heap_form_tuple is not present in the included headers
[ ] MemoryContextDelete is not present in the included headers
[ ] BackgroundWorker has a new field: bgw_start_rule
[ ] ProcessInterrupts now expects two arguments, a *const c_char and c_int?

To solve each of these problems, some or all of the following might be necessary:

a new feature must be defined to use with #[cfg] attributes
some relevant code in PGRX will have to be changed with #[cfg]
a new header may need to be defined for that version to compile against
problems with how we invoke bindgen might need to be addressed
cargo pgrx and pgrx-pg-config's version detection powers may need to be enhanced

Last but not least, the documentation will have to be significantly enhanced in order to steer people appropriately when they e.g. inevitably try to compile an extension against an "unqualified" PostgreSQL 12 but actually need to compile against Greenplum 7. Code will also have to consider how certain messages that talk about Postgres versions may now have to start talking about Greenplum versions as well, and how we should explain that to people.

Jun 24 '23 19:06 workingjubilee

Hello,

I am currently working on adding support for Greenplum 7 to pgrx. I've introduced a new feature flag called "gp7". At this moment, it can compile within an existing GP project by using the following commands:

export PGRX_PG_CONFIG_PATH=${Where-your-GP-pg_config}
cargo build --features gp7 --no-default-features

May I contribute my code to your project? If so, please let me know what else needs to be done. As far as I'm aware, the remaining tasks include integrating tests for GP7, determining whether there is a need to interface with various cargo-pgrx commands (such as cargo pgrx init/run), as well as some documentation work.

Mar 19 '24 08:03 cyccbxhl

Hello,

I am currently working on adding support for Greenplum 7 to pgrx. I've introduced a new feature flag called "gp7". At this moment, it can compile within an existing GP project by using the following commands:
export PGRX_PG_CONFIG_PATH=${Where-your-GP-pg_config}
cargo build --features gp7 --no-default-features
May I contribute my code to your project? If so, please let me know what else needs to be done. As far as I'm aware, the remaining tasks include integrating tests for GP7, determining whether there is a need to interface with various cargo-pgrx commands (such as cargo pgrx init/run), as well as some documentation work.

it will be a great job. I did some similar works and most of tests/examples can work well by now. I think the demo cluster in Greenplum source code is good enough for test and run command. This is how I run and test in fact.

I will be glad to help if needed so make pgrx support GP7.

Apr 09 '24 13:04 lij55

Hi @lij55. I’d like to discuss this with someone at Greenplum. I think we’d need/want/require additional CI resources beyond what GHA provides.

Is Ivan still there? If so, please ask him to email me: [email protected].

In the mean time, could you put up a PR so we can get a feel for the scope of changes?

Thank you!

/cc @ChronicallyJD

Apr 09 '24 14:04 eeeebbbbrrrr

Hi @eeeebbbbrrrr ,

I left Greenplum about one year ago but I would be glad to help to reach to Ivan. my working branch (https://github.com/lij55/pgrx/commits/gptest/) is still in very early stage. it is very hacking and dirty so far but as POC it works anyway. It requires Greenplum code change as well as you mentioned.

I believe the guys reacting in this (https://github.com/pgcentralfoundation/pgrx/issues/1179#issuecomment-2006252019) are from Greenplum. we are ex-colleagus :)

Apr 09 '24 15:04 lij55

Me or @ChronicallyJD will reach out to Ivan. I'd like this to be a coordinated effort between all interested parties.

Us taking on long-term ownership of integration with a Postgres fork without help from the people behind it is my primary concern.

Apr 09 '24 15:04 eeeebbbbrrrr

I can reach out to Ivan. I know him rather well.

Founder -https://commandprompt.com/ - 24x7x365 Postgres since 1997
Founder and Co-Chair -https://postgresconf.org/
Founder -https://postgresql.us- United States PostgreSQL
Public speaker, published author, postgresql expert, and people believer.
Host -More than a refresh: A podcast about data and the people who wrangle it.

On Tuesday, April 9th, 2024 at 8:26 AM, Eric Ridge @.***> wrote:

Me or @.***(https://github.com/ChronicallyJD) will reach out to Ivan. I'd like this to be a coordinated effort between all interested parties.

Us taking on long-term ownership of integration with a Postgres fork without help from the people behind it is my primary concern.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

Apr 09 '24 17:04 ChronicallyJD

After some behind the scenes talks, it looks like we're not going to be able to support GP as a "postgres version", so the likelihood of us accepting such PRs is at zero.

That said, any PRs anyone would like to upstream that generally fix pgrx bugs or add new features, we'd definitely want.

May 01 '24 16:05 eeeebbbbrrrr

Greenplum has been archived, it seems.

https://github.com/greenplum-db/gpdb-archive

Jun 03 '24 21:06 workingjubilee

Greenplum has been archived, it seems.

https://github.com/greenplum-db/gpdb-archive

Hi @workingjubilee, Any chance to reopen this issue? I want to share more backgrounds here for your information.

As you know, Greenplum went closed-source from this May. Now Cloudberry Database (https://github.com/cloudberrydb/cloudberrydb), one derivative & fork version of Greenplum 7, is out. Cloudberry is created by the original developers of Greenplum, and ships with a newer PostgreSQL kernel (currently using 14.4, and plan for annual upgrades) and lots of advanced features. Cloudberry Database is set to keep compatible with Greenplum. If want to continue this work, then will be more easier.

Our Cloudberry Database team also would like to be involved and provide technical assistance. I'd like to know if you guys are interested in the PGRX for Cloudberry. If so, then we can discuss this further.

Aug 21 '24 03:08 tuhaihe

Right now, the best path is to discuss with Joshua Drake (JD). https://github.com/ChronicallyJD. He manages the pgcentral foundation.

From the core team’s perspective, we can’t take on the workload of supporting a Postgres fork without significant support from those involved in the fork. This would mean CI resources, Human Resources, and financial support.

We will, of course, review and likely merge general PRs that aren’t specific to your fork. That sort of change is clearly valuable on its own.

/cc @ChronicallyJD

Aug 21 '24 03:08 eeeebbbbrrrr

Hi @eeeebbbbrrrr thanks for your kind reply!

Hi @ChronicallyJD, nice to meet you! I'm the community manager of Cloudberry at HashData. I'd like to schedule a call to explore the potential possibility of PGRX for Cloudberry and discuss what we can do for this.

I'm not sure if you're available next week. If you are, please feel free to schedule a meeting via my Calendly: https://calendly.com/wangdianjin/45min. Looking forward to the meeting!

Aug 22 '24 03:08 tuhaihe

and ships with a newer PostgreSQL kernel (currently using 14.4, and plan for annual upgrades)

Ah! If something can be worked out re: the relevant CI-related details and such, that will make pgrx support much easier.

Aug 23 '24 01:08 workingjubilee

Hello, I'm a member of the Cloudberry development community, like @tuhaihe, and I'm interested in contributing to this initiative or offering official support for a PostgreSQL fork (Cloudberry Database, based on PG 14.4). As a former Greenplum community member, my interest in PGRX stems from my desire to provide the latest PostgresML extension for Cloudberry DB.

Regarding the core team’s perspective on the workload, I fully understand that supporting a PostgreSQL fork requires significant resources, including CI, Human Resources, and financial backing. I am committed to helping address these needs and would be happy to collaborate on finding the necessary support to ensure the success of this initiative.

Additionally, the Cloudberry project is actively working on an Apache Cloudberry proposal to solidify our open-source standing and, at all costs, avoid the community issues that have affected the Greenplum project.

Sep 11 '24 19:09 edespino