![]() ![]() This comes a bit closer to planning than guessing for minor versions, as the minor versions of PostgreSQL do not change the file system they only change the binaries. That is a bit over-optimistic about new bugs being introduced and kind of ignores that new features that you don’t care about have to be configured-or else. The general idea is that all software has bugs, and upgrading is better than not upgrading. This is the general recommendation of the PostgreSQL Global Development Group. Myth 3: “Upgrade for every minor version” Unfortunately, it ignores the bugs you don't even know exist. This is based on the idea that the bugs we know are better than the bugs we don't know. The complete opposite fear-based pseudo-plan is to stick to the existing version-come hell or high water-unless you run into an otherwise unfixable bug that affects your installation. This makes for a very aggressive upgrade pace and hopes for a better tomorrow rather than a stable today. It is a very Rumsfeldian plan that assumes you don't know what the bugs are, but you're certainly better off if they're fixed. This "plan" is based on the fear of existing bugs. Myth 1: “Upgrade as fast as possible, every time” Let's start with some of the community's conventional wisdom and pretend that those ideas were actually a plan of sorts. The actual upgrade implementation was always left as an exercise for the administrator. These tools were meant to make upgrades possible, not to imply any particular schedule or recommendations for an upgrade plan. This seems a bit of a harsh statement when tools like pg_upgrade exist but bear with me. The developers of PostgreSQL never really had a plan in mind for when and how to upgrade. Since there are only two external stimuli, there are only two choices: upgrade the binaries (minor version change) or upgrade the data on disk (major version change). The PostgreSQL Global Development Group has simplified the upgrade process quite a bit with more explicit version numbering. By the end of this post, we will introduce you to our best practices for upgrading your PostgreSQL version in Timescale, so you can get over this process of upgrading as quickly and safely as possible. That is, when you should upgrade and what PostgreSQL version you should select as a target. This blog post will hopefully serve as a guide for when to pull off the old band-aid. It's just too exhausting to generate emotion anymore. There's not even any joy about all the new features and speed. Eventually, you just want it to be over so you can take a nap. It's almost like finishing a long hike or trying to convince somebody that Betamax was better than VHS. So, when the community heartily recommends that you should upgrade as soon as possible to the latest and greatest PostgreSQL version, it's not really surprising that your heart sinks, your mouth goes dry, and the outright dread of another laborious job takes over. PostgreSQL has a long-standing reputation for having a miserable upgrade process. ![]()
0 Comments
Leave a Reply. |