Обсуждение: Bug introduced in 8.0
Hi all, I have a new job and dba rol with PostgreSQL, they have installed PostgreSQL 8.0.2, but I found this release have some bugs, fixed in newer versions, I interesting particulary on this bug: "Fix bug introduced in 8.0 that could allow ReadBuffer to return an already-used page as new, potentially causing loss of recently-committed data (Tom)" http://www.postgresql.org/docs/8.0/static/release-8-0-6.html I know an upgrade is a best solution but it's impossible now for me (I do not have authorization), my answer is, what exactly means this bug? is serious? sorry poor english. Please help, thanks. Sergio.
On Tue, Aug 26, 2008 at 08:21:53AM -0300, Sergio Gabriel Rodriguez wrote: > "Fix bug introduced in 8.0 that could allow ReadBuffer to return an > already-used page as new, potentially causing loss of > recently-committed data (Tom)" > http://www.postgresql.org/docs/8.0/static/release-8-0-6.html > > I know an upgrade is a best solution but it's impossible now for me (I > do not have authorization), my answer is, what exactly means this bug? > is serious? Yes, it's serious. It means that you can lose data that has been committed. Get authorization. You can install the latest version of the 8.0.x software directly in place, with no dump or restore. It's a drop-in replacement. The minor releases are security and stability releases. If your management thinks that they are optional to install, then get that in writing, because they are instructing you to run known-dangerous software. They are being negligent. Patching your software for known defects is not "upgrading", it's "doing your job." A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/
On Tue, Aug 26, 2008 at 7:10 AM, Andrew Sullivan <ajs@commandprompt.com> wrote: > > The minor releases are security and stability releases. If your > management thinks that they are optional to install, then get that in > writing, because they are instructing you to run known-dangerous > software. They are being negligent. Patching your software for known > defects is not "upgrading", it's "doing your job." Also, start looking for another job where your bosses aren't idiots.
Scott Marlowe wrote: > Also, start looking for another job where your bosses aren't idiots. For many, the choice of whether to work for an idiot or not is the choice to be employed or not. Mark Twain observed that at age nineteen, a young man finds his father to be the stupidest man in the world, but year by year thereafter finds that his father was smarter and smarter. What managers manage is risk. Naturally they can only manage perceived risk. The perception is that new software produces new risk, and from that perspective it is not idiotic but quite reasonable to resist change. They aren't idiots, they're just under-educated. One who knows better has a fiduciary responsibility to their employer to inform them of risks of which they wot not. In the case of "minor" version upgrades to PG, it is our duty to inform our bosses of the risk of not upgrading, so they can properly assess risks and manage them accordingly. -- Lew
On Tue, Aug 26, 2008 at 08:46:33PM -0400, Lew wrote: > upgrades to PG, it is our duty to inform our bosses of the risk of not > upgrading, so they can properly assess risks and manage them accordingly. I agree. It is, by the same token, your duty to yourself to ensure that, if the answer is, "No," you get that answer in writing so that future failures are not possibly pinned on you as having been negligent in installing stability and security releases. By the way, I always refer to these of late as "security and stability" rather than "minor" releases. I do that because it presents them to the target audience in a way that is understandable. Those releases are, for the project, a maintenance burden and not a way to introduce features. It's wise to keep that in mind when presenting such releases to managers responsible for the decision. A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/
On Wed, Aug 27, 2008 at 10:58 AM, Andrew Sullivan <ajs@commandprompt.com> wrote: > On Tue, Aug 26, 2008 at 08:46:33PM -0400, Lew wrote: >> upgrades to PG, it is our duty to inform our bosses of the risk of not >> upgrading, so they can properly assess risks and manage them accordingly. > > I agree. It is, by the same token, your duty to yourself to ensure > that, if the answer is, "No," you get that answer in writing so that > future failures are not possibly pinned on you as having been > negligent in installing stability and security releases. > > By the way, I always refer to these of late as "security and > stability" rather than "minor" releases. I do that because it > presents them to the target audience in a way that is understandable. > Those releases are, for the project, a maintenance burden and not a > way to introduce features. It's wise to keep that in mind when > presenting such releases to managers responsible for the decision. I used to work for an Oracle DBA and while he was quite smart in most ways, he really had been trained by Oracle to avoid anything but "patches". Upgrades / updates of a db were very scary for him. I had to present the minor updates as "patch releases" to get him comfortable with them. And have a full implementation plan and all that as well. But if instead he had insisted on running an outdated version of PostgreSQL for some goofy reason I would have been looking for another job. I guess I've been lucky in that I've never actually had to work for idiots. Sure have interviewed with quite a few though.
Scott Marlowe wrote: > On Wed, Aug 27, 2008 at 10:58 AM, Andrew Sullivan <ajs@commandprompt.com> wrote: > > On Tue, Aug 26, 2008 at 08:46:33PM -0400, Lew wrote: > >> upgrades to PG, it is our duty to inform our bosses of the risk of not > >> upgrading, so they can properly assess risks and manage them accordingly. > > > > I agree. It is, by the same token, your duty to yourself to ensure > > that, if the answer is, "No," you get that answer in writing so that > > future failures are not possibly pinned on you as having been > > negligent in installing stability and security releases. > > > > By the way, I always refer to these of late as "security and > > stability" rather than "minor" releases. I do that because it > > presents them to the target audience in a way that is understandable. > > Those releases are, for the project, a maintenance burden and not a > > way to introduce features. It's wise to keep that in mind when > > presenting such releases to managers responsible for the decision. > > I used to work for an Oracle DBA and while he was quite smart in most > ways, he really had been trained by Oracle to avoid anything but > "patches". Upgrades / updates of a db were very scary for him. I had > to present the minor updates as "patch releases" to get him > comfortable with them. And have a full implementation plan and all > that as well. > > But if instead he had insisted on running an outdated version of > PostgreSQL for some goofy reason I would have been looking for another > job. The major problem is that much software doesn't have our stability in minor releases, and hence the perception that many minor release are risks is accurate, just not in the Postgres case. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +