MogDB 3.0.2 is a patch version of MogDB 3.0.0, which is released on September 16 of 2022. It mainly involves bug fixes based on MogDB 3.0.1.
\nVersion upgrade optimization: support direct upgrade from v2.0 to v3.0 (without the need to upgrade MogDB from v2.0 to v2.1)
\nThe gsql '\\l' command adds the function of displaying the database.
\nFix the defect that the database frequently prints warning log after the undo_retention_time parameter is enabled.
\nFix the defect that an error is reported once gs_global_chain cannot be found during vacuum or analyze execution after version upgrade.
\nFix the defect that the data in the new tablespace of the primary server cannot be synchronized to the standby server in the primary/standby stream replication.
\nFix the defect that an error is reported when log_min_messages is set to debug5 during the operation of CREATE or SELECT.
\nFix the defect that \"error parameter when release fake relation\" is continuously reported when the fields of partition table is updated.
\nOptimize the insertion of the xlog record in the x86 system.
\nFix the defect that the ustore zone overflows even if the ustore table is not used when the pressure of the short link service is high.
\nFix the defect that the tuples following the cluster command are disordered due to row-level compression.
\nModify the function of not using asynchronous commit for transactions in vacuum.
\nFix the hang problem probably caused by enabling thread pool.
\nFix the hang problem probably caused because no trace data is written during the gstrace stop operation.
\nFix the defect of repeatedly parsing data after restarting an application when an LSN error is reported in multi-transaction scenarios after parallel decoding is enabled.
\nFix the coredump probably caused by asynchronous submission.
\nFix the database coredump caused by manually adding row lock to the view.
\nFix the coredump caused by parallel replay or extreme recovery in page compression scenarios.
\nFix the coredump caused by frequent creation and deletion of a database in the primary database and the database is connected by the standby database using gsql in the primary/standby deployment scenarios.
\nFix the coredump caused by creating a domain with the same name after dropping table of type and using the field in a package.
\n| No. | \nProblem Description | \nImpact Analysis | \nEvasion and Contingency Measures | \n
|---|---|---|---|
| 1 | \nThe coredump problem probably occurred in the standby database under the primary/standby pressure test | \nRisk: high (impact level: high; probability of occurrence: low) When the primary database frequently creates database and drops database, it will cause the standby database to load the invalid data pages into the buffer pool when it plays back the data, thus causing a coredump. | \nWorkaround: Avoiding frequent database creation and drop operations can reduce the probability of occurrence, but it cannot be completely avoided. Contingency measure: N/A | \n
| 2 | \nIn the primary/standby pressure test, the standby database may have the problem that some modified data cannot be found. | \nRisk: high (impact level: high; probability of occurrence: medium) In some cases, querying data from the standby database will not find the data that has just been updated, and the phenomenon is similar to data being deleted. | \nWorkaround: When the standby database is queried, set the hot_standby_feedback parameter to avoid the data that needs to be queried from being reclaimed prematurely by the primary database. Contingency measure: N/A | \n
| 3 | \nAfter the version upgrade, operators such as >, >=, <, <=, =, etc. can be used for point types. In general, the point type cannot use these operators. | \nRisk: low (impact level: low; probability of occurrence: high) After the upgrade, the operators that correspond to the point type works, but an error is still reported. | \nWorkaround: This type is not an ordinary data type and is not usually used. If you do need to report an error, you can manually remove the operator metadata corresponding to the type to solve it. Contingency measure: N/A | \n
| 4 | \nAfter the upgrade, the Oracle dbms_job.user_export can return results when the parameters are illegal. In general, an illegal parameter error is reported. | \nRisk: low (impact level: low; probability of occurrence: high) After the upgrade, the arm machine can return results when the parameter is illegal. | \nWorkaround: It is considered normal. If you do need to report an error here, you need to reinstall the Oracle compatibility extension. Contingency measure: N/A | \n