GSoC 2025

From PostgreSQL wiki
Jump to navigationJump to search
This page is for collecting ideas for Google Summer of Code 2025 projects. This page is for IDEAS ONLY.

IF YOU ARE A CONTRIBUTOR: there is a top-level GSoC page for PostgreSQL here: PostgreSQL General GSoC Page - please read this first before proceeding to contact mentors! Contribution guidelines, channels and communication methods are in this page too. PLEASE make sure you have read everything thoroughly.

If you are a mentor and would like to participate, feel free to edit this page and put your name below.

Mentors mailing list for proposals: gsoc2025-mentors@lists.postgresql.org

Proposals

Proposals are still work in progress. If you are a mentor and would like to participate, feel free to edit this page and put your name below.

Admins

  • Jesper Pedersen
  • Pavlo Golub

Mentors

The following individuals have been listed as possible mentors on the below projects, and/or offered to be mentors for student-proposed projects:

  • Pavlo Golub
  • Jesper Pedersen
  • David Wheeler
  • Mark Wong

<PROJECT NAME GOES HERE>

Project Description

<PROJECT DESCRIPTION GOES HERE>

Skills needed

  • ...
  • ...
  • PostgreSQL

Difficulty level

Easy, moderate, hard, insane

Project size

~90 hours, ~175 hours, or ~350 hours

Mentors

  • Person 1
  • Person 2

Expected outcomes

  • Working implementation of ...

References

  • link 1
  • link 2
  • PostgreSQL

ABI Compliance Checker

Project Description

Develop and deploy an "ABI Compliance Checker", to be integrated into the PostgreSQL development process similar to coverage.postgresql.org. The checker should run on every commit to the project and produce an ABI compliance report, and trigger an alert when an ABI has changed in an incompatible way. See this thread for an example of such a report, and some details on how it was implemented. Use it as starting point for building the tool.

Once the tool reliably produces reports, work with the infrastructure team to get it added to the development pipeline and to publicly publish its reports.

Background

PostgreSQL recently added Server API and ABI Stability Guidance to help extension authors to understand how and when the server API and ABI are and are not likely to change. In practice, the guidance is that the API and ABI should maintain compatibility between minor releases (e.g., 17.0 to 17.1), but not major releases. This has long been the implicit guidance, but now it is explicit, and due to be included in the PostgreSQL 18 docs.

Today the committers adhere to this policy purely through the review process, which means once in a while an incompatible change will be included in a minor release. Such changes have been extremely rare, but this past fall an ABI change was unexpectedly shipped in PostgreSQL 17.1. It was quickly reversed in PostgreSQL 17.2, but highlights the need for some process to catch such changes before they're released.

This project will help reduce the change of such an incident again by automatically checking for ABI changes. This will improve the adherence to the guidance, perhaps allow it to be upgraded to a reliability _policy_, and give extension developers and package maintainers assurance about the reliability of extension builds on PostgreSQL minor releases.

Skills needed

  • C Programming
  • Command-line tooling
  • HTML & CSS
  • Service deployment
  • Automation

Difficulty level

Moderate

Project size

175 hours

Mentors

  • David Wheeler

Expected outcomes

  • Working implementation of a subdomain of postgresql.org or as part of the build farm featuring ABI compatibility reports for every commit pushed to a back branch of PostgreSQL
  • Notifications of failures sent via email to the committers
  • Git repository for the project for ongoing maintenance
  • Integration into the PostgreSQL infrastructure build and deploy processes

References

pg_top data internal data structure refactor

Project Description

pg_top is a terminal tool to monitor the top running PostgreSQL processes. This project is to port and use libbsd's red-black tree data structure.

pg_top doesn't need all of what libbsd has to offer, so it makes more sense to just port tree.h.

If time permits, additional tasks can be added to improve pg_top.

Background

pg_top currently uses libbsd's red-black tree data structure to organize process information but this library is not easily used on some platforms, like MacOS. The code base previously used home-grown linked lists, but I think it would be nice to use an existing library rather than revert the code.

Skills needed

  • C Programming

Difficulty level

Moderate

Project size

175 hours

Mentors

  • Mark Wong

Expected outcomes

  • pg_top functions with ported tree.h code for at least Linux

References

Retrieved from "https://wiki.postgresql.org/index.php?title=GSoC_2025&oldid=40453"