Skip to content

PostgreSQL Project @ GSoC 2022

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.

 

 

Continue reading "PostgreSQL Project @ GSoC 2022"

GSoC 2021 completed

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.

 

Continue reading "GSoC 2021 completed"

PostgreSQL Project @ GSoC 2021

Wow! The PostgreSQL Project got all 7 proposals accepted into Google Summer of Code 2021!

This year Google changed the participation terms a bit, and cut the time for the students in half. This is supposed to help students who can’t work full-time from home, especially in light of the global pandemic situation. It also means smaller projects, which are easier to handle even for students new to the project.

The PostgreSQL project got a great number of initial applications (29), and we talked with many of the students about refining their proposals. 27 out of the 29 applications were finally submitted by the students. Some are duplicates, some are clearly just copied from somewhere, but many propose good ideas.

After talking with available mentors, and “recruiting” a few more, we settled on 7 final applications, and submitted them to Google.

As usual many of the proposals are not directly developing code for core PostgreSQL, but work on tools and applications from the PostgreSQL ecosystem. Expect some great output over the following months.
 

Google Summer of Code 2020 - Intermediate status update

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!

Google Summer of Code 2020 started

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!

Google Summer of Code 2019 - PostgreSQL participates with 5 projects

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.

Continue reading "Google Summer of Code 2019 - PostgreSQL participates with 5 projects"

GSoC 2011 - phpPgAdmin

Google Summer of Code 2011 is in the second term. Leonardo Sápiras passed the midterm evaluation and continues his work on the phpPgAdmin plugin infrastructure.

His work is already in an advanced stage, time to take a look and show you, what's possible.

Continue reading "GSoC 2011 - phpPgAdmin"

GSoC 2011 - Big changes in phpPgAdmin

After many years in the PostgreSQL community, I applied as a co-mentor for the phpPgAdmin project and was accepted. More specifically, the project is about a plugin architecture to extend phpPgAdmin, Leonardo Sápiras has submitted this proposal and was accepted. Jehan-Guillaume (ioguix) de Rorthais is the main mentor for this project.
If we had known beforehand how many questions a simple objection can raise - who knows if I would have been accepted as co-mentor;-)

One of the key issues in the new architecture is how plugins are implemented. Without describing all the gory details, here are the two discussed options:

On one hand this is possible if each plugin make's his own output, stays in his own subdirectory and is called directly from the browser. Otherwise there is very little interaction with the rest of the code.

Another option is to register all plugins in the phpPgAdmin core and make use of hooks to call certain functions of the plugins whenever necessary.

This question was only raised because the first approach requires including lib.inc.php from files which are not in the root directory of phpPgAdmin - this is not possible right now. At this point I provocatively raised the question of what a plugin is. And why a completely separate file in a subdirectory may call himself a "plugin".

The current consent is to implement the second option. This approach offers much greater possibilities. However, this approach may require refactoring of parts of the code in the future to make use of the new plugin architecture. Possibly even as part of another GSoC project.