The pgconf.dev conference, a revamp of the original PGCon, happened about two weeks ago. It’s the main event for Postgres developers, and one of the things we’re trying is an Advanced Patch Feedback Session (APFS).

We first tried that last year in Vancouver, and then again in Montreal. But I realized many people attending the conference either are not aware of the event at all, or are not sure what it’s about. So let me explain, and share some reflections from this year.

What is the APFS for?

The schedule entry from pgconf.dev 2025 describes the APFS session like this:

Participants will work in small groups with a Postgres committer to analyze a past contribution or attempted contribution, discussing what they could have done better both in the patch and communication about the patch.

This workshop is by invitation only; as part of the application process, we’ll ask you which of your currently pending or previous patches you would like to discuss.

This description is pretty terse, and would deserve more detail. And the description from 2024 seems much more detailed. At least the announcement we sent to pgsql-hackers is better, but considering the volume of emails on that list, it’s easy to miss stuff.

The APFS is meant to be an informal workshop, discussing selected patches (submitted and selected in advance). The goal is to identify challenges patches are facing, and give some advice on how to proceed.

That was the original idea, at least - to look at “old” patches that got “stuck”. But this year we had a couple patches that were relatively new, and the contributors were asking for general advice on how to proceed when submitting / discussing them on the mailing list.

My impression is it was good to include those new-ish patches.

So it’s a patch review?

I want to stress out that APFS is not meant to be an in-depth technical review. And it’s not meant to teach how to do a patch review. A proper review of a patch can take hours or even days, especially for complex patches and patches stuck for non-obvious reasons. Like those submitted for APFS.

I think the APFS is meant as a place to share two kinds of feedback that may be difficult to share in messages on a mailing list:

• Explain how the reviewers (and ultimately committers) are thinking about patches. How they weigh the risks/benefits of a patch. Or even how they decide which patch to review next.

• Give some general “strategic” advice. Ways to advocate for a patch, increase the chance of reaching consensus or how to respond to rejection constructively.

I think the advice is not particularly mysterious. It’s common sense stuff like to break the patch into smaller parts, to make reviews easier and allow incremental commits. Or to add a hook so that something can be done from an extension, to reduce the risk for everyone. But it’s easier to talk about this in the context of actual patches, it feels less abstract.

Of course, some of the patches have technical issues, and there can be a discussion about that. But it’s not a line-by-line review.

Getting a patch into APFS

Let’s say you’re a contributor, you submitted a patch and you’re not sure why or how to get it moving again. The APFS is meant to try to help with that, but how do you get a patch into APFS?

It’s an informal workshop, but there’s still a small CfP-like process to select the patches, independent of the regular call for talks. It was announced about two months before the event. You’d apply with one or more patches, and the APFS organizers (which this year was Robert Haas, Amit Kapila and myself) would pick the patches.

And then we’d match the patches with committers who volunteered for the APFS, and form the groups of the “right” size. We wanted at least two committers in each group (to have multiple points of view etc.), but large groups make discussion harder. This year we had only two, each with 2 committers and 6-8 attendees. Last year there were three groups, but the groups were a bit smaller if I recall.

The session is meant to be fairly informal, so it’s largely up to each group how they organize and structure the discussion. This is how our group approached it, and I think it worked pretty well.

We didn’t want the session to turn into a series of 1:1 conversations between committers and a single patch author, with other attendees quietly waiting for their turn. We wanted to encourage a wider discussion - attendees asking questions about other patches, share opinions or even give advice.

So at the beginning we asked everyone to briefly present their patch, the questions they have (if any) and express what they expect from the APFS. Sometimes the questions were technical, sometimes it was more about how to advocate for the patch, etc.

I think this was a good way to start the session, as it gave people a better perspective of what the challenges / questions are. It was clear that some questions are similar/shared, etc.

And then we went around, and discussed the patches in more detail. We didn’t have a strict time limit, but it worked out to about 20-30 minutes per patch quite naturally.

Conclusions

The session felt fairly productive, and the discussion seemed reasonably balanced. I’m sure I talked too much, but I hope everyone had a chance to ask questions or express opinions.

Luckily, the APFS was on the first day of the conference. I know it has allowed people to have follow-up discussions about their patches over the next few days.

Of course, I don’t know if we “unstuck” all the patches, but I hope the attendees got some actionable advice that will help them. Possibly with some future patch.

There’s no reason why similar sessions could not happen at other conferences. Yes, pgconf.dev is the main developer conference. But other Postgres conferences are attended by developers/committers too.