ads' corner

As is a good tradition, the PostgreSQL Project participates in Google Summer of Code (GSoC). Last year we submitted 7 projects for 7 students - and got all 7 projects accepted. This year we got quite a few more good proposals from students, and more mentors are helping. Guess what? Google accepted all 12 proposals!

Google modified the program again. For 2021 they cut the time for every project in half, to accommodate for the at-home work during the Covid-19 pandemic. This turned out to be suboptimal, and many larger projects need more time. This year students can choose between “medium” (175 hours) and “large” (350 hours) projects. This gives everyone a chance to scope the project accordingly.

The Google Summer of Code 2021 for the PostgreSQL Project is wrapped up. The timeline this year was shortened to half, compared to previous years. That’s good, because smaller projects can be worked on, and students have a chance to cope with a changing environment at home and university. On the other hand, the shorter time doesn’t allow diving into more complex projects. Nevertheless, with the help of all mentors, six students successfully concluded their projects.

The three PostgreSQL projects for this year’s Google Summer of Code are on track, and making good progress. All projects expect to finish on time.

Performance Farm

The data gathering for performance farm members is completed, as well as the new implementation for the JSON data transfer. The project iteratively updated it’s goals, and adjusted for newly identified UI issues.

Current work centers around making the website more pretty and useful, as well as reducing the number of used JavaScript libraries. The next step is presenting the work to the PostgreSQL Community for broader feedback.

PL/Java build system

The PL/Java project has just merged (PR #288) the first major pull request of new code from GSoC, creating a new plugin for the Maven build system that allows its actions to be guided by script snippets clearly exposed in the build files.

The same effect was formerly achieved by a workable but brittle combination of an existing Maven plugin that could handle most of the build requirements with another plugin that was able to run Ant, which was able to run scripts. That resulted in a non-ideal division of labor, where a good deal of build logic was hidden away inside plugins, while some parts were exposed in script out of necessity, rather than because they were interesting or likely to need adjustment.

This pull request proves the concept of a new plugin where the hardcoded Java portions are the uninteresting building blocks, and the overall logic of the build is clearly exposed in script.

For now, the new plugin is used to retire the maven-javadoc-plugin and remove the constraints it had imposed on the project's javadocs (such as the need for absolute URLs for intermodule references, making the resulting tree hard to preview or relocate).

Work continues to reimplement the C native build and retire the nar-maven-plugin and maven-antrun-plugin, to be delivered in a future PR.

WAL-G Performance

We’ve just completed the decoupling of the complex WAL-G internal class. Thanks to it, the new functionality developed in July for a more intelligent backup creation process can now be safely integrated. This feature involves major changes so it requires time to verify that everything is working as expected. We plan to finish the integration in parallel with working on other features.

Currently, we are working on merging the new series of commands for the WAL archives that have been uploaded to storage. These commands will allow end users to analyze the storage for any missing WAL segments that may prevent performing a PITR. Also, Dan now is in the process of implementing the last feature and he expects to finish it on time.

Thanks to all mentors for the status update!

The PostgreSQL Project participates in Google Summer of Code (GSoC) 2020, with 3 projects. After the “Community Bonding” period finished last week, we are now in the active development phase - “Coding” as Google calls it. All three projects make good progress!

Performance Farm

The project defined a number of milestones, and evaluated the current database structure. Modifications are required on this front, and will be applied over the following days. Also the structure for sending data from the client to the project server is re-evaluated and modified. The student started with the database design modifications, and also with documenting the changes and terminology used.

PL/Java build system

Thanks to the ongoing work setting up the continuous integration, PL/Java's master branch - which will become the 1.6 release - is now getting regular CI builds against several PostgreSQL and Java versions on amd64 Ubuntu and Mac OS X, and the student has moved on to setting up the same for Windows. We had a goal to enable test options in the CI builds that were otherwise impractically strict, and identify ways to filter the output down to a manageable volume which is exposing real issues. Through a combination of fixes to some real PL/Java warnings, and a small state machine now keeping known non-PL/Java ones out of the log, the project now builds -Xcheck:jni clean. The first actual bug found through the students work got fixed before the bonding period ended - the bug had been there for fifteen years.

The later part of the work will involve more straight-up coding, to replace a Maven plugin now used in PL/Java's build that isn't quite suited to the need. The proposal outlined a few reasons for that and the preliminary work has already uncovered more reasons. It was already a goal of that work to improve the signal-to-noise ratio of diagnostics from that plugin, so already solving a similar problem for -Xcheck:jni was a good warmup.

WAL-G performance

First 2 weeks are going almost as we planned, the student started working on the first task during the phase of proposals. In the first week he updated his PR and we merged it. The first feature already works. This week he updated it with several improvements (mostly refactorings) and started working on test coverage of the first feature and also making some drafts on the second feature. Now we have discussion about design details of the second feature. I hope it will help to implement it according to the current plan.

Thank you to all mentors for the status update!

For the 13th year, the PostgreSQL Project is participating in Google Summer of Code (GSoC). This project is a great opportunity to let students learn about Open Source projects, and help them deliver new features. It is also a chance to engage the students beyond just one summer, and grow them into active contributors.

In GSoC, students first learn about the Open Source organization, and either pick a summer project from the list provided by the org, or submit their own idea for review. After a “community bonding” period, the students have time to implement their idea, under supervision of mentors from the Open Source organization. There is also an incentive: first, Google pays the students for their work on improving Open Source projects. And second, having a completed GSoC project in a CV is well recognized.