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?
VP, Chief Database Scientist @ EnterpriseDB, PostgreSQL Major Contributor and Committer
Thursday, May 25, 2023
Do I Really Need That backup_label File?
Friday, April 14, 2023
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.
Monday, April 10, 2023
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.
Tuesday, April 04, 2023
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.
Tuesday, January 24, 2023
Surviving Without A Superuser - Coming to v16
Friday, November 04, 2022
pg_basebackup could not set compression worker count - unsupported parameter
Monday, May 02, 2022
Parallel Server-Side Backup Compression
I decided to do a little more research on the performance of server-side backup compression, which will be a new feature in PostgreSQL 15 unless, for some reason, the changes need to be reverted prior to release time. The network link I used for my previous testing was, as I mentioned, rather slow, and handicapped by both a VPN link and an SSH tunnel. Furthermore, I was testing using pgbench data, which is extremely compressible. In addition, at the time I did those tests, we had added support for LZ4 compression, but we had not yet added support for Zstandard compression. Now, however, we not only have Zstandard as an option, but it is possible to use the library's multi-threading capabilities. So, I wanted to find out how things would work out on a faster network link, with a better test data set, and with all the compression algorithms that we now have available.