This blog is about my work on the Postgres open source database, and is published on Planet PostgreSQL. PgLife allows monitoring of all Postgres community activity.
Online status:
Unread Postgres emails:
Email graphs:
incoming,
outgoing,
unread,
commits
(details)
Researching Upgrade Changes
Monday, June 13, 2022
Postgres issues major and minor releases regularly, as outlined on the Postgres website. Figuring out what changes are part of each upgrade can be confusing. Let's look at how to find the relevant Postgres changes for simple and complex upgrades:
- Upgrade from one recent minor release to a later minor release with the same major version number: Suppose you are running Postgres 13.4 and want to upgrade to 13.7 — well, that's easy — just read the minor release notes for each of the minor versions that span your old and new versions.
- Upgrade from the most recent minor release to a newly released major version: Suppose you are running the most recent release of Postgres, 13.7, and Postgres 14 is released — well, that's pretty easy. The Postgres 14 major release notes contain all the changes between Postgres 13.7 and 14.
- Upgrade from a non-newest minor release to a newly released major version: Suppose you are running a non-newest version of Postgres, 13.5, and Postgres 14 is released. You should read the release notes of all 13.x minor releases after 13.5, and the Postgres 14 major release notes. Reading the 13.x minor release notes is necessary because changes made after 13.5 will be part of Postgres 14 but not listed in the Postgres 14 release notes.
- Upgrade from a non-newest minor release to a minor release of the next released major version: Suppose you are running Postgres 13.5 and want to upgrade to 14.3. You should read the release notes of all 13.x minor releases after 13.5, the Postgres 14 major release notes, and the minor release notes from 14.1 to 14.3.
- Upgrade from a non-newest minor release to a minor release of a much later major version: Suppose you are running Postgres 11.7 and want to upgrade to 14.3. You should read the release notes of all 11.x minor releases after 11.7, the Postgres 12-14 major release notes, and the minor release notes from 14.1 to 14.3. However, you should also scan the 12.x and 13.x minor release notes because they might contain fixes to features added in their respective major releases.
This website lists all the changes from one release to another.
In other release note news, last month I announced the Postgres 15 beta release notes, but it lacked markup. Two days ago I completed adding markup to the release notes, which should make them easier to use. This markup will also appear in the next beta release. Also, I am hosting a panel discussion about Postgres upgrades on Wednesday at Postgres Vision.
View or Post Comments Postgres 15 Release Notes
Monday, May 16, 2022
I have just completed the first draft of the Postgres 15 release notes. It includes developer community feedback but still needs more xml markup and links.
The release note feature count is 186, which is similar to recent major releases, excluding Postgres 14's high feature count. Postgres 15 Beta 1 should be released soon. The final Postgres 15 release is planned for September/October of this year.
View or Post Comments
Postgres in the Microservices World
Wednesday, April 20, 2022
I try to keep current on database industry needs, and how Postgres meets or can be enhanced to meet those needs. One of my recent areas of study was microservices — the result is 111-slides on the topic. I am glad to announce that Postgres TV has scheduled the inaugural presentation of these slides for tomorrow at noon, U.S. Eastern time. A recording will be available after the event.
View or Post Comments
Abuse of Open Source?
Monday, April 4, 2022
With the Russian invasion of Ukraine, there is renewed focus on the use of Postgres by governments, particularly uses that might further military goals.
The unintended use of technology is nothing new. Alfred Nobel's invention of dynamite prompted the creation of the Nobel Peace Prize to promote peace. Manhattan Project engineers unsuccessfully tried to control the use of the atomic bomb they created.
In the software industry, companies have tried to control the use of proprietary software, with mixed success. Cloud and web services are better able to control access because authentication and continuous connectivity are often required. Social media companies also exert control over who can use and what can be said on their platforms.
The licenses used by open source software don't support these traditional use-regulation methods because there is no required interaction between software producers and users. This was done consciously to promote adoption and independent usage (particularly the Postgres license). Attempts to limit the use of open source software by the U.S. Immigration and Customs Enforcement (ice) agency have largely been unsuccessful. Attempts to limit Russia's use of Postgres, even for projects directly contributing to the war effort, are also likely to be ineffective.
Changing the Postgres license now would not change the license of previous versions, and even if we could go back in time and change the license, the net effect would likely be negative for the project and ineffective at controlling usage. In summary, once you create something, it is hard to control it, and very hard without legal/governmental support.
Update: depesz has blocked access to his website and services from Russia and Belarus. 2022-04-13
View or Post Comments
RSS
