Praise, Criticism, and Dialogue

When my children were little and I was trying to figure out how to be a parent, I read someplace that you need to have five positive interactions with your child for each negative one to maintain a good relationship. I don't know whether that is fact or myth; a quick Google search suggests that the origin of the idea was in a study about how married couples argue, the idea being that in a good marriage, positive things continue to happen even amidst disagreement. It's wise to be wary about applying a number discovered in a very specific context more generally, but there's a compelling idea here: positive interactions build us up, and negative ones break us down, regardless of whether we're talking about a spouse, a child, or, say, the PostgreSQL community. Too many negative interactions and we just feel like giving up.

The PostgreSQL Documentation and the Limitations of Community

In my opinion, the PostgreSQL documentation is simultaneously excellent and fairly poor, and both its excellence and its shortcomings are direct results of the process by which the documentation is produced. The PostgreSQL documentation is stored in the same git repository as the source code, and anyone who patches the source code so as to change documented behavior must also patch the documentation to match.

Do I Really Need That backup_label File?

I'm sure you already know what I'm going to tell you: "Of course you need that backup_label file. How could you even think that you don't need that backup_label file?" Well, you're right. That is what I'm going to say. But do you know why you need that backup_label file? If you were to remove that backup_label file (or fail to create in the first place, in cases where that is your responsibility), what exactly is the bad thing that would happen to you?

Who Contributed to PostgreSQL Development in 2022?

As in previous years, I've pulled together a few statistics on code contributions to PostgreSQL. See previous posts in this series for methodology and caveats. I calculate that, in 2022, there were 192 people who were the principal author of at least one PostgreSQL commit. 66% of the new lines of code were contributed by one of 14 people, and 90% of the new lines of code were contributed by one of 40 people. Here they are.  Asterisks indicate non-committers.

Updating the Cost Limit On The Fly

Rejoice and be glad! I was so pleased this morning to see that Melanie Plageman's patch to make autovacuum absorb new cost limit settings more quickly was committed by Daniel Gustafsson while I was busy enjoying a long Easter weekend. It's a minor change in the grand scheme of things, but there's a reasonably common situation where it's going to make life a lot easier.

Assigning Blame For PostgreSQL Errors

If an error message shows up in the PostgreSQL log, what program is malfunctioning? It's easy to conclude that the answer is PostgreSQL, but that's too simplistic.

Surviving Without A Superuser - Coming to v16

As I've written about before, a PostgreSQL superuser always has the ability to take over the operating system account in which PostgreSQL is running, but sometimes you'd like to have a role that can administer the database but not break out of it. In existing releases, there's no good way to accomplish that. You can either make a new role so weak that it can't perform ordinary administration tasks, or you can make it so strong that it can easily break into the operating system account and thus take over the superuser role as well. Unless you hack the source code, which some people have done, there's no real way to set up an account that has enough power to usefully administer the database in meaningful ways but yet not enough power to take over everything. I've committed a number of patches to v16 to try to improve the situation, and I think that we can look forward to big improvements in this area once it is released.