[KSB] This is a difficult one to answer. I went through release notes for releases going back to 2007 checking for bugs we fixed that could cause data loss. There were a few that pertained to the REORG (defragmentation) operation if it was run while applications were actively using and updating the database. We did not patch existing GT.M releases, since the workaround was to run the reorg when there were not active users on the system, or to to run reorg (databases tend not to get fragmented in normal use except under certain pathological access patterns). We did have one fix to a bug that could cause data loss, but it was an edge case encountered in our own test environment and never encountered in a user site. It was fixed in a subsequent release. I personally cannot remember any production site where the root cause of a data loss was a GT.M bug. We do expect sites to set up GT.M applications correctly, e.g.:
On 02/11/2014 04:35 PM (US Eastern Time), Thorsten Alteholz wrote:
On Tue, 11 Feb 2014, Bhaskar, K.S wrote:
Dominique's suggestion makes sense. There's no issue changing the latest release and having fis-gtm reflect that, so that someone installing fis-gtm always gets the latest release. My concern is just to make sure that installing the latest release when fis-gtm is updated should not delete prior releases already on the system.
So for testing the user needs to install the versionless package fis-gtm and such will get updates and informations about problems with the current versions.
With respect to Thorsten's question about security and grave bugs: So far, we have been lucky and to date have never had a grave bug that caused us to withdraw a release.
This is good to hear, but now we need to agree on the meaning of grave :-).
According to https://www.debian.org/Bugs/Developer#severities a grave bug can cause data loss. So you never had such a bug? Everybody could use the version from oldstable forever and will just miss some new features? Anyways, if this would happen, would you (as upstream) provide patches for older versions?
- We do expect sites running databases containing data that they care about to run with journaling turned on (and use replication, depending on the specific need). If you are running without journaling, and the system crashes, your database may be very difficult to recover manually. But if you are running with before-image journaling, GT.M automatically recovers the database, with journal records that have been committed to disk. [In the event of a system crash, anything in flight that is still in memory is of course lost. GT.M has transaction processing functionality for situations when transaction Durability is a must, and in those cases will not move past a TCommit command until it has done an fsync to disk. This is how online financial transactions are handled by the FIS Profile core banking application built on GT.M.]
- We do expect sites running applications with databases that have data they care about to make sure they don't run out of space, especially in the journal file system. And as added protection, we do expect sites that cannot guarantee that they are monitoring the space so that they don't run out of it to use functionality in GT.M that freezes updates when you run out of space.
- We do expect sites to not randomly kill shared memory segments and randomly kill processes with kill -9. [GT.M has logic that tries to recover after a process is terminated with a kill -9, but that logic cannot unconditionally recover.]
So, while it is possible to set up a database and lose data, if you set it up correctly (and we have a lot of training material), you should expect to never lose data. GT.M even tries to protect itself against its own bugs by detecting and cleaning up out of design conditions.[KSB] It is hard for me to generalize from such a small sample. Our action would depend on the nature of the vulnerability, the nature of the fix and the nature of the workaround. So, while we can promise to take security seriously (and we have to, because GT.M today is the database of record for well over a hundred million bank accounts around the world), we can't promise a solution without knowledge of a problem it must solve.
With respect to security issues, we have had two security issues in the last so many years (actually, one issue in 2007, followed by a second because the fix for the first issue was not complete). As the vulnerability was not in the GT.M core, we were able to distribute a fix that wrapped & isolated the vulnerable component and could be retrofitted to existing installations of older releases.
Ok, in such a rare case you will provide the needed patches or workarounds for all versions in Debian?