Thanks for your feedback! The issue has been fixed, please refer the latest PR: https://github.com/cloudberry-contrib/postgis/pull/9 Thank you for reporting this issue.
As the same time, I think it's necessary to build a CI to ensure that new commits do not break existing code in future. Best, Wei Han > From: "Ed Espino"<[email protected]> > Date: Thu, Oct 16, 2025, 15:09 > Subject: PostGIS 3.3.2 Testing - Distributed Query Memory Corruption Issue > To: <[email protected]> > Hi Cloudberry Team, > > I wanted to share findings from testing PostGIS 3.3.2 with Cloudberry and > see if we can learn from this experience together. > > Issue Summary: > > While attempting to validate the PostGIS 3.3.2 integration by running its > embedded regression test suite, I encountered critical memory corruption in > distributed > queries with spatial predicates. I've filed a detailed bug report with > reproduction steps: > > GitHub Issue: [Bug] PostGIS Memory Corruption in Distributed Querieshttps:// > github.com/apache/cloudberry/issues/1395 > > The issue manifests as consistent crashes (mcxt.c:933 assertion failures) > when executing cross-segment joins with geometry operations like > ST_Contains and > ST_Intersection. Single-segment queries work fine. > > Testing Approach: > > My goal was straightforward: run PostGIS's own regression test suite > against Cloudberry to validate the integration. The embedded tests are > designed to exercise > PostGIS functionality comprehensively, and they revealed this distributed > architecture incompatibility immediately. > > Questions for the Community: > > I'm curious about the testing methodology used during the PostGIS 3.3.2 > upgrade work: > > 1. What testing was performed to validate the PostGIS 3.3.2 integration? > 2. Were the PostGIS embedded regression tests run against Cloudberry's > distributed architecture? > 3. If testing was done, were distributed queries with geometry joins > tested, or primarily single-segment scenarios? > > I'm asking not to point fingers, but to understand where we can improve our > extension testing practices. This seems like a gap we should address > systematically. > > Opportunity for Improvement: > > Running upstream extension test suites against Cloudberry's distributed > architecture seems like valuable validation that could catch integration > issues early. Would > the community be interested in: > > - Establishing testing guidelines for extension upgrades? > - Sharing test frameworks/approaches for distributed query validation? > - Creating a checklist for extension integration testing? > > The full technical analysis, core dumps, and test reproduction suite are > available in the GitHub issue. Happy to discuss findings or testing > approaches. > > Best regards, > -=e > -- > Ed Espino > Apache Cloudberry (Incubating) & MADlib >
