Contents

2008 R4.4 Release Notes

Release Notes Information

This document includes information on CUBRID 2008 R4.4(Build No. 8.4.4.0227). CUBRID 2008 R4.4 includes all of the fixed errors and improved features that were detected in the CUBRID 2008 R4.3 version and were applied to the previous versions.

For details on the CUBRID 2008 R4.3, see http://release.cubrid.org/en.

Overview

CUBRID 2008 R4.4 is a version of stabilizing 2008 R4.3 and improving administrative convenience.

CUBRID 2008 R4.4's DB volume is compatible with CUBRID 2008 R4.3's. Therefore, you do not need database migration. For details, see Upgrade.

Improvements in Administrative Convenience

  • Add SQL profiling features
  • Add or Improve the features of CUBRID administrative tools(utilities) which execute features such as printing various status information or managing transactions.
  • Strengthen the log messages to facilitate the verification of information on each status.

Stablization in HA replication

  • Fix the problems that some particular queries are not replicated.
  • Fix replication delay phenomenon or connection error.

Improvements in Sharding Features

  • Add a command that allows to see the shard ID corresponding to the SHARD key.
  • Fix to be able to dynamically adjust the number of CAS for SHARD proxy.
  • Fix access errors and query processing errors.

Behavioral Changes

  • Fix so that there is no case to violate constraints such as PRIMARY KEY or NOT NULL when running "ALTER .. ADD COLUMN"
  • Remove SELECT_AUTO_COMMIT, a broker parameter.
  • The range of a value for APPL_SERVER_MAX_SIZE_HARD_LIMIT broker parameter is limited to a value between 1 and 2,097,151.
  • The default setting of broker parameter SQL_LOG_MAX_SIZE that specifies the size of the SQL log file has been changed to 10MB from 100MB.
  • In JDBC, zero date value of TIMESTAMP is changed into '0001-01-01 00:00:00' from '1970-01-01 00:00:00'(GST) when the value of zeroDateTimeBehavior property in connection URL is "round".

Configuration

  • A user can specify capacity units or time units in the parameters to enter the capacity or time.

Driver Compatibility

  • The JDBC and CCI driver of CUBRID 2008 R4.4 are compatible with the DB server of CUBRID 2008 R4.3 or before.

For more details on changes, see the following. Users of previous versions should check the Behavioral Changes and New Cautions sections.

New Features

Administrative Convenience

Support SQL profiling(CUBRIDSUS-10984)

The SQL profiling feature is added for analyzing query performance.

The SQL profiling information is output when executing the "SHOW TRACE" statement after executing the "SET TRACE ON" statement and queries as follows:

csql> SET TRACE ON;
csql> SELECT /*+ RECOMPILE */ o.host_year, o.host_nation, o.host_city, n.name, SUM(p.gold), SUM(p.silver), SUM(p.bronze)
        FROM OLYMPIC o, PARTICIPANT p, NATION n
        WHERE o.host_year = p.host_year AND p.nation_code = n.code AND p.gold > 10
        GROUP BY o.host_nation;
csql> SHOW TRACE;

  trace
======================
  '
Query Plan:
  SORT (group by)
    NESTED LOOPS (inner join)
      NESTED LOOPS (inner join)
        TABLE SCAN (o)
        INDEX SCAN (p.fk_participant_host_year) (key range: (o.host_year=p.host_year))
      INDEX SCAN (n.pk_nation_code) (key range: p.nation_code=n.code)

  rewritten query: select o.host_year, o.host_nation, o.host_city, n.[name], sum(p.gold), sum(p.silver), sum(p.bronze) from OLYMPIC o, PARTICIPANT p, NATION n where (o.host_year=p.host_year and p.nation_code=n.code and (p.gold> ?:0 )) group by o.host_nation

Trace Statistics:
  SELECT (time: 1, fetch: 1059, ioread: 2)
    SCAN (table: olympic), (heap time: 0, fetch: 26, ioread: 0, readrows: 25, rows: 25)
      SCAN (index: participant.fk_participant_host_year), (btree time: 1, fetch: 945, ioread: 2, readkeys: 5, filteredkeys: 5, rows: 916) (lookup time: 0, rows: 38)
        SCAN (index: nation.pk_nation_code), (btree time: 0, fetch: 76, ioread: 0, readkeys: 38, filteredkeys: 38, rows: 38) (lookup time: 0, rows: 38)
    GROUPBY (time: 0, sort: true, page: 0, ioread: 0, rows: 5)
'

tranlist utility(CUBRIDSUS-9601)

"cubrid tranlist" utility which shows the transaction information of the database. DBA and DBA groups are only allowed to use it.

% cubrid tranlist -s testdb

Tran index         User name      Host name      Process id          Program name
-------------------------------------------------------------------------------------
   1(ACTIVE)         PUBLIC        myhost            1822           broker1_cub_cas_1
   2(ACTIVE)            dba        myhost            1823           broker1_cub_cas_2
   3(COMMITTED)         dba        myhost            1824           broker1_cub_cas_3
-------------------------------------------------------------------------------------

Sort by the column specified in the tranlist command and output the result(CUBRIDSUS-9655)

A feature to sort by the column specified in the "cubrid tranlist" command and output the result is added.

The following example shows how to sort by specifying the fourth column, "Process id," and output the information.

% cubrid tranlist --sort-key=4 tdb

Tran index    User name Host name Process id           Program name  Query time Tran time Wait for lock holder  SQL_ID         SQL Text
--------------------------------------------------------------------------------------------------------------------------------------------------------------
   1(ACTIVE)     PUBLIC    myhost      20080 query_editor_cub_cas_1        0.00      0.00                   -1  *** empty ***
   3(ABORTED)    PUBLIC    myhost      20081 query_editor_cub_cas_2        0.00      0.00                   -1  *** empty ***
   2(ACTIVE)     PUBLIC    myhost      20082 query_editor_cub_cas_3        0.00      0.00                   -1  *** empty ***
   4(ACTIVE)     PUBLIC    myhost      20083 query_editor_cub_cas_4        1.80      1.80              2, 3, 1  cdcb58552e320  update ta set a=5 where a > ?
--------------------------------------------------------------------------------------------------------------------------------------------------------------

Tran index : 4
update ta set a=5 where a > ?

killtran utility can remove transactions with SQL ID(CUBRIDSUS-9653)

killtran utility has ability to remove transactions which executes a designated SQL.

% cubrid killtran --query-exec-info testdb

Tran index  Process id  Program name             Query time   Tran time  Wait for lock holder     SQL ID      SQL Text
--------------------------------------------------------------------------------------------------------------------------------------------
  1(ACTIVE)    26650    query_editor_cub_cas_1        0.00         0.00                    -1  *** empty ***
  2(ACTIVE)    26652    query_editor_cub_cas_3        0.00         0.00                    -1  *** empty ***
  3(ACTIVE)    26651    query_editor_cub_cas_2        0.00         0.00                    -1  *** empty ***
  4(ACTIVE)    26653    query_editor_cub_cas_4        1.80         1.80               2, 1, 3  cdcb58552e320  update ta set a = 5 where a > 0
--------------------------------------------------------------------------------------------------------------------------------------------

SQL_ID: cdcb58552e320
Tran index : 4
update ta set a = 5 where a > 0

% cubrid killtran --kill-sql-id=cdcb58552e320 -f testdb

-i option of killtran utility accepts multiple transactions(CUBRIDSUS-9601)

You can specify several transactions with -i option of the killtran utility to remove them at once.

% cubrid killtran -i 1,3,8 testdb

Show parameters of running broker and shard(CUBRIDSUS-10901)

"cubrid broker info" command shows the parameter information of running broker and "cubrid shard info" command shows the parameter information of running shard.

Event log file to record the status which affects query performance(CUBRIDSUS-10986)

An additional event log file is added to record the status such as SLOW_QUERY, MANY_IOREADS, LOCK_TIMEOUT, DEADLOCK, and TEMP_VOLUME_EXPAND that affects query performance.

For more details, see Event Log.

cub_master log file includes each node information in the output of HA status(CUBRIDSUS-11113)

When split-brain, fail-over, or failback occurs, information on each node is included in the log file of the cub_master process. The format of a log file is $CUBRID/log/<host_name>.cub_master.err.

The cub_master log file of the master node, which terminates itself to clear the split-brain status, includes the node information as follows:

Time: 05/31/13 17:38:29.138 - ERROR *** file ../../src/executables/master_heartbeat.c, line 714 ERROR CODE = -988 Tran = -1, EID = 19
Node event: More than one master detected and local processes and cub_master will be terminated.

Time: 05/31/13 17:38:32.337 - ERROR *** file ../../src/executables/master_heartbeat.c, line 4493 ERROR CODE = -988 Tran = -1, EID = 20
Node event:HA Node Information
================================================================================
 * group_id : hagrp   host_name : testhost02    state : unknown
--------------------------------------------------------------------------------
name                priority   state          score      missed heartbeat
--------------------------------------------------------------------------------
testhost03          3          slave          3          0
testhost02          2          master         2          0
testhost01          1          master         -32767     0
================================================================================

The cub_master log file of the node that is changed to the master after fail-over or changed to the slave after failback includes the node information as shown below.

Time: 06/04/13 15:23:28.056 - ERROR *** file ../../src/executables/master_heartbeat.c, line 957 ERROR CODE = -988 Tran = -1, EID = 25
Node event: Failover completed.

Time: 06/04/13 15:23:28.056 - ERROR *** file ../../src/executables/master_heartbeat.c, line 4484 ERROR CODE = -988 Tran = -1, EID = 26
Node event: HA Node Information
================================================================================
 * group_id : hagrp   host_name : testhost02    state : master
--------------------------------------------------------------------------------
name                 priority   state           score      missed heartbeat
--------------------------------------------------------------------------------
testhost03           3          slave           3          0
testhost02           2          to-be-master    -4094      0
testhost01           1          unknown         32767      0
================================================================================

HA

The failover method is changed with the "-i" option when executing "cubrid heartbeat stop" command(CUBRIDSUS-9572)

When the "cubrid heartbeat stop" command was executed, failover started after all of the HA server and utilities had been terminated. If any server processes or utilities had not been terminated, they were forcibly terminated. After the update, if replication mismatch does not occur during termination even though server processes are not terminated, the remaining utilities are terminated and failover proceeds immediately.

DB restoration time is not required upon restarting HA as server processes are not forcibly terminated.

In the updated version, if the -i option is added to the "cubrid heartbeat stop" command, server processes and utilities are immediately terminated and failover proceeds.

Sharding

"cubrid shard getid" command to print the shard ID for the shard key(CUBRIDSUS-9547)

"cubrid shard getid" command prints the shard ID for the shard key.

The following example prints the shard ID for shard key 1 on shard1, the shard proxy:

% cubrid shard getid -b shard1 1

The -f option dumps all information of the shard ID.

% cubrid shard getid -b shard1 -f 1

Use the cci_set_db_parameter function(CUBRIDSUS-10125)

The cci_set_db_parameter function can be used in the SHARD environment; isolation level and lock timeout can be configured in the SHARD environment.

The password of shard DB can be specified with an environment variable(CUBRIDSUS-11570)

Now SHARD_DB_PASSWORD of shard.conf can be specified with an environment variable.

This environment variable is used when you don't want to expose SHARD_DB_PASSWORD to shard.conf. The name format of this environment variable is "<shard_broker_name>_SHARD_DB_PASSWORD"; if <shard_broker_name> is shard1, the name of this environment variable becomes SHARD1_SHARD_DB_PASSWORD.

export SHARD1_SHARD_DB_PASSWORD=shard123

Configuration

Add a parameter to adjust the maximum number of replication archive logs(CUBRIDSUS-11377)

The ha_copy_log_max_archives parameter, which adjusts the maximum number of replication archive logs, is added. In the previous versions, the log_max_archives parameter was used to specify both the maximum number of transaction archive logs and the maximum number of replication archive logs.

Add a system parameter to specify transaction rollback when lock escalation occurs(CUBRIDSUS-11384)

The rollback_on_lock_escalation parameter is added to specify transaction rollback when lock escalation occurs.

When this parameter is configured to yes, an error log is recorded without escalation when lock escalation occurs; the corresponding lock request fails and the transaction is rolled back. When it is configured to no, lock escalation is executed and the transaction continues to proceed.

Behavioral Changes

SQL

PRIMARY KEY or NOT NULL constraint is not violated when a column without a default value is added to a table containing a record by using the ALTER statement(CUBRIDSUS-9725)

When a column without a default value is added by using the ALTER ... ADD COLUMN statement, the PRIMARY KEY or NOT NULL constraint was violated as all values of the added columns became NULL. This problem has been fixed.

In the updated version,

  • If the constraint of a column to add to a table containing a record is the PRIMARY KEY, the error is returned.
  • If the constraint of a column to add is NOT NULL and the configuration value of add_column_update_hard_default in cubrid.conf is no, the error is returned.

Driver

[JDBC] Change zero date of TIMESTAMP into '1970-01-01 00:00:00'(GST) from '0001-01-01 00:00:00' when the value of zeroDateTimeBehavior in the connection URL is "round"(CUBRIDSUS-11612)

When the value of the property "zeroDateTimeBehavior" in the connection URL is "round", the zero date value of TIMESTAMP is changed into '1970-01-01 00:00:00'(GST) from '0001-01-01 00:00:00'.

[JDBC][CCI] Query timeout is applied to the batch processing function(CUBRIDSUS-10088)

Fix to apply the queryTimeout to the batch processing functions (the cci_execute_batch function and the cci_execute_array function) and the executeBatch method of JDBC or when the CCI_EXEC_QUERY_ALL flag is assigned to the cci_execute function. The queryTimeout for the batch processing function is applied in the unit of a function (or method); not by separate SQL unit.

Utility

Changes on "cubrid broker status" command(CUBRIDSUS-9602)

Changes on "cubrid broker status" command are as follows:

  • Only the status of the executing brokers are shown when you run "cubrid broker status SERVICE=ON".
$ cubrid broker status SERVICE=ON

% query_editor
----------------------------------------------------------------------
        ID   PID                  QPS        LQS   PSIZE STATUS
----------------------------------------------------------------------
         1 20370                    0          0   52456 IDLE
         2 20371                    0          0   52456 IDLE
         3 20372                    0          0   52456 IDLE
         4 20373                    0          0   52456 IDLE
         5 20374                    0          0   52456 IDLE
  • with -b option,
  • The first 20 characters of the broker name are shown. When the broker name exceeds 20 characters, '...' is printed right after the first 20 characters of the broker name.
  • The REQ item is no longer provided.
  • To show QPS and TPS as unsigned 64-bits integer. In previous versions, negative numbers was shown when an overflow happened.
  • Add #CONNECT to provide the sum of the number of connections to the CAS processes belongs to the broker.
  • The SELECT, INSERT, UPDATE, DELETE and OTHERS items show the number of query executions for each. However -f option is given, these items are not printed.
  • UNIQUE-ERR-Q shows the number of unique key violation errors.
  • without -b option,
  • "CLIENT_WAIT" and "CLOSE_WAIT" are shown instead of "CLIENT WAIT" and "CLOSE WAIT".
  • The broker configuration is no longer provided.
  • When -l option is given, the information of CAS whose status is "CLOSE_WAIT" is excluded.

Configuration

Time unit or capacity unit next to the time or capacity parameter value can be specified(CUBRIDSUS-10412)

The time unit or the capacity unit is specified next to the system parameter(cubrid.conf), the broker parameter(cubrid_broker.conf) and the shard parameter(shard.conf) where the time or the capacity is entered.

In the following table, the right parameters are recommended for use instead of the left parameters.

Deprecated New
lock_timeout_in_secs lock_timeout
checkpoint_every_npages checkpoint_every_size
checkpoint_interval_in_mins checkpoint_interval
max_flush_pages_per_second max_flush_size_per_second
sync_on_nflush sync_on_flush_size
sql_trace_slow_msecs sql_trace_slow

The input unit and the meaning of the parameters are as follows:

Classification Input Unit Meaning
Capacity B Bytes
K Kilobytes
M Megabytes
G Gigabytes
T Terabytes
Time ms milliseconds
s seconds
min minutes
h hours

The input unit and the meaning of the parameters are as follows:

Classification Parameter Name Acceptable Unit
System backup_volume_max_size_bytes B,K,M,G,T
checkpoint_every_size B,K,M,G,T
checkpoint_interval ms, s, min, h
group_concat_max_len B,K,M,G,T
lock_timeout ms, s, min, h
max_flush_size_per_second B,K,M,G,T
sql_trace_slow ms, s, min, h
sync_on_flush_size B,K,M,G,T
string_max_size_bytes B,K,M,G,T
thread_stacksize B,K,M,G,T
Broker APPL_SERVER_MAX_SIZE_HARD_LIMIT B, K, M, G
LONG_QUERY_TIME ms, s, min, h
LONG_TRANSACTION_TIME ms, s, min, h
MAX_QUERY_TIMEOUT ms, s, min, h
SESSION_TIMEOUT ms, s, min, h
SQL_LOG_MAX_SIZE B, K, M, G
TIME_TO_KILL ms, s, min, h
Shard PROXY_LOG_MAX_SIZE B, K, M, G
PROXY_TIMEOUT ms, s, min, h

Change the upper limit of the sort_buffer_size system parameter to 2G(CUBRIDSUS-9582)

Change the upper limit of the sort_buffer_size system parameter to 2G. In previous versions, the server was abnormally terminated when sort_buffer_size was set to a value larger than 2G and more thant 2G of sort_buffer was actually used, such as loading a huge index.

Remove OFF option from KEEP_CONNECTION broker parameter(CUBRIDSUS-5316)

Remove OFF option from the broker parameter, KEEP_CONNECTION. In 2008 R4.x and earlier versions, when it is set to OFF, the user-defined variable and the LAST_INSERT_ID, ROW_COUNT, PREPARE statement are not executed normally.

Change APPL_SERVER_MAX_SIZE_HARD_LIMIT broker parameter(CUBRIDSUS-10260)

Change the permitted range of the value of APPL_SERVER_MAX_SIZE_HARD_LIMIT broker parameter as 1 to 2,097,151. If the value is out of the range, it is not allowed for the broker to be executed. In addition, when the value of APPL_SERVER_MAX_SIZE_HARD_LIMIT is changed to a value smaller than APPL_SERVER_MAX_SIZE by using broker_changer, a warning message is displayed.

Change the default value of SQL_LOG_MAX_SIZE broker parameter from 100MB to 10MB(CUBRIDSUS-9944)

Change the default value of SQL_LOG_MAX_SIZE of cubrid_broker.conf from 100MB to 10MB. If a user of a previous version wants to leave SQL logs equivalent to the existing volume of the SQL logs after upgrade, please set the value of SQL_LOG_MAX_SIZE to 100,000 (unit: KB).

Other

Feature of asynchronous query is no longer supported(CUBRIDSUS-11265)

When a query is executed by the CSQL Interpreter or by specifying the CCI_EXEC_ASYNC flag in the cci_execute function, the asynchronous query feature that can receive the interim query result is no longer supported.

Improvements and Fixes

Performance and Optimization

Query plan is rewritten when the data volume is increased from the small data(CUBRIDSUS-3382)

If the data volume changed after the previous prepare exceeds critical when prepare is re-executed for the same query, the query plan is rewritten.

In the following query, the idx1 index is used when the first SELECT statement is executed. When the second SELECT statement is executed, the query plan is rewritten to use the idx2 index.

CREATE TABLE foo (a INT, b INT, c STRING);
INSERT INTO foo VALUES(1, 1, REPEAT('c', 3000));
CREATE UNIQUE INDEX idx1 ON foo (a, c);
CREATE INDEX idx2 ON foo (a);

SELECT a, b FROM foo WHERE a = 1; -- 1st

INSERT INTO foo SELECT a+1, b, c FROM foo;
INSERT INTO foo SELECT a+2, b, c FROM foo;
INSERT INTO foo SELECT a+4, b, c FROM foo;
INSERT INTO foo SELECT a+8, b, c FROM foo;
INSERT INTO foo SELECT a+16, b, c FROM foo;
INSERT INTO foo SELECT a+32, b, c FROM foo;
INSERT INTO foo SELECT a+64, b, c FROM foo;
INSERT INTO foo SELECT a+128, b, c FROM foo;

SELECT a, b FROM foo WHERE a = 1; -- 2nd

Statistical information of only the added index is updated(CUBRIDSUS-10709)

In the previous versions, the statistical information of all existing indexes was updated and it became a burden on the system. Now, to remove this burden, the statistical information of the added indexes is only created.

Reduce time to fork new CAS processes(CUBRIDSUS-10825)

As the number of application connections grows, it is required to fork new CAS processes upto MAX_NUM_APPL_SERVER broker parameter. 2008 R4.4 or 9.1 version reduces time to fork new CAS processes. For example, when MIN_NUM_APPL_SERVER is 100 and MAX_NUM_APPL_SERVER is 400, it took over 30 seconds to fork 300 new CAS processes. 9.1 takes 3 seconds.

Resource

Fix memory leak of 'cubrid shard status' command(CUBRIDSUS-10393)

Fix memory leak of "cubrid shard status -c -s 1" command which periodically prints the shard status information.

Disk write operation still continued even when the SQL_LOG mode of the broker had been dynamically changed to OFF(CUBRIDSUS-10765)

Disk Write (IO write) continued because of SQL log even when the SQL_LOG mode of the broker was changed from ON to OFF in operating the DB. This problem has been fixed. In the previous versions, when the SQL LOG mode was dynamically changed to OFF, the SQL log seemed to not be written because the log was written on the disk and then the file pointer was turned back. This problem has been fixed to no log actually being written on the disk.

Too much memory was used while restoring backup volume of large DB(CUBRIDSUS-11843)

Problem of too much memory being used when restoring backup volume of large DB has been fixed. For example, in the previous versions, when the DB page size was 16 KB and the DB size was 2.2 TB, if the level 0 backup file was restored, at least 8 GB memory was required. Now, the memory is not required.

However, in the updated version, a lot of memory may be required for restoring the level 1 or 2 backup files.

Stability

Query scanning index was not stopped(CUBRIDSUS-11945)

The issue of query that scans index not closing and temporary temp volume being infinitely increased has been fixed.

First query execution failed when DB restarted after the driver had been connected(CUBRIDSUS-10773)

The issue of the first query execution failing with the error message below when DB restarted after the driver was connected has been fixed.

Server no longer responding.... Invalid argument
Your transaction has been aborted by the system due to server failure or mode change.
A database has not been restarted.

New access request took more than 30 seconds while the CAS was frequently started or terminated(CUBRIDSUS-10891)

When MIN_NUM_APPL_SERVER in cubrid_broker.conf is smaller than MAX_NUM_APPL_SERVER, the CAS may be started or terminated according to the number of requests from the driver. It sometimes took more than 30 seconds to request for a new access when the CAS was frequently started or terminated. This problem has been fixed.

DB server process hang due to internal issues of lock manager(CUBRIDSUS-10329)(CUBRIDSUS-11983)

Fix an issue that lock manager might cause server process hang while acquiring a lock. Fix another internal issue due to an incorrect lock timeout.

Memory leak and abnormal termination of server that might occur while detecting a deadlock(CUBRIDSUS-10378)

Fix the problem that memory is leaked in a special status and the server can be abnormally terminated while detecting a deadlock.

Error that might occur when a checkpoint occurs while allocating a new page in standalone mode(CUBRIDSUS-10444)

Fix the error "Skip invalid page in checkpoint" might occur when a checkpoint operation occurred while allocating a new page in the standalone mode.

CAS hang in CLIENT WAIT state(CUBRIDSUS-10238)

Fix an issue can be happened when a CAS was terminated by a signal or abnormally terminated at a particular timepoint, the CAS or broker process would wait indefinitely.

Abnormal CAS termination when network socket error occurred in CAS while receiving DB server error(CUBRIDSUS-10401)

Fix abnormal termination of CAS process when a network socket error happens while it is receiving a DB server error. In previous versions, SHARD CAS was abnormally terminated when "cubrid shard start" was executed while the MAX_NUM_APPL_SERVER value of cubrid_shard.conf (which set the number of shard CAS processes) was larger than the max_clients value of cubrid.conf (which set the maximum number of connections for the server) in the SHARD environment.

Purge unneeded archive logs(CUBRIDSUS-10757)

Fix to clearly purge the unneeded archive logs. This issue can happen when a checkpoint operation is executed when there are many data flush operations.

In Windows, DB server process is hung when it is restarted(CUBRIDSUS-12028)

Fix the problem that DB server process is hung when it is restarted in Windows. This problem occurs only in Windows XP or before and Windows 2003 or before, and it does not occur in Windows 7 or Windows 2008.

SQL

Incorrect query result when the left outer join query included the WHERE clause condition(CUBRIDSUS-8867)

Fix the problem that would cause an incorrect query result to be output when the WHERE clause was included in the query in which the left outer join was nested three times or more, as shown in the following example:

SELECT *
FROM tblA LEFT OUTER JOIN tblB ON tblA.pkey = tblB.pkey
          LEFT OUTER JOIN tblC ON tblB.p2key = tblC.p2key
          LEFT OUTER JOIN tblD ON tblC.p3key = tblD.p3key
WHERE tblD.p3key = 1;

Failure to RENAME the table that included the AUTO_INCREMENT column(CUBRIDSUS-9691)

Fix an error that occurred when changing the name of a table that included the AUTO_INCREMENT attribute.

-96 Error when an INSERT statement was re-executed after a table was created under Auto Commit OFF and then a unique key violation occurs(CUBRIDSUS-10239)

The -96 error would occur when the INSERT statement was re-executed after a table had been created under Auto Commit OFF, and then a unique key violation would occur while executing the INSERT statement. This error has been fixed.

% csql testdb --no-auto-commit
CREATE TABLE tbl(col1 INTEGER UNIQUE);
INSERT INTO tbl SELECT 500 + ROWNUM FROM db_class a, db_class b;
INSERT INTO tbl SELECT ROWNUM FROM db_class a, db_class b;
ERROR: Operation would have caused one or more unique constraint violations. INDEX u_t_i(B+tree: 0|139|540) ON CLASS t(CLASS_OID: 0|486|2). key: 501(OID: 0|551|358).
INSERT INTO tbl SELECT 500 + ROWNUM FROM db_class a, db_class b;
ERROR: Media recovery may be needed on volume "/home1/cubrid1/CUBRID/databases/testdb/testdb".

Failure to execute the INSERT statement due to the error of splitting the index node, as a result of many duplicate keys(CUBRIDSUS-9829)

As the list of duplicate record addresses was large due to many duplicate keys, the INSERT statement failed to execute by selecting an incorrect node to split the index leaf node. This problem has been fixed.

Problem that would cause an incorrect query result to be returned when false conditions have been given as an operand of the OR operator(CUBRIDSUS-10475)

CREATE TABLE tab0 (col1 INTEGER);
INSERT INTO tab0 VALUES (514);
INSERT INTO tab0 VALUES (698);

-- The following query should output 0 case; however, two cases have been output in the previous versions:
SELECT * FROM tab0 WHERE (col1 BETWEEN 9 AND 2) OR (col1 BETWEEN 5 AND 4);

Error occurring when lob type data was read in the 32-bit version(CUBRIDSUS-10437)

UPDATE tbl SET b = CHAR_TO_CLOB ('2test') WHERE a = 1;

Problem that an application is abnormally terminated when otehr query statements than the SELECT statement are executed even when only the query plan would be shown by setting an optimization level(CUBRIDSUS-9771)

An application was abnormally terminated when some other SQL statements than a SELECT statement, such as INSERT, UPDATE, DELETE, REPLACE, TRIGGER, and SERIAL, were executed even when only the query plan would be shown by setting the query optimization level. This problem has been fixed that some other SQL statements than a SELECT satatement did not show the query plan.

SET OPTIMIZATION LEVEL 514;
REPLACE INTO tbl (col1, col2, col3) VALUES (1, 2, 3);

Query plan was not outputted when an IN clause had a host variable (CUBRIDSUS-9705)

Fix an error in which the query plan would not be outputted when an IN clause contains a host variable in the form of (?, ?, ...).

csql> ;plan detail
csql> SELECT * FROM tbl WHERE id IN (?, ?, ?);

Incorrect results when WITH ROLLUP corrector of a GROUP BY clause was specified (CUBRIDSUS-9926)

Fix a problem in which incorrect results would be produced when the WITH ROLLUP corrector of the GROUP BY clause was specified.

// The results was not outputted with ROLLUP.
SELECT a FROM t1 GROUP BY A WITH ROLLUP;

// The results was outputted with ROLLUP even though it should not be outputted since the column value was NULL and a>1.
SELECT a, COUNT(*) FROM t1 GROUP BY a WITH ROLLUP HAVING a>1;

Error when a subquery has been specified as an input argument of the SQL function in the query statement without the FROM clause(CUBRIDSUS-9949)

When a subquery was specified as the input argument of the SQL function for the query statement without the FROM clause, the error "ERROR: syntax is ambiguous" would occur. This error has been fixed.

SELECT INET_NTOA ((SELECT 3232235530));

Failure to execute INSERT by using the Host variable for the NUMERIC type column(CUBRIDSUS-11366)

When executing INSERT by using the host variable for the NUMERIC type column, the type of input value was changed into the default precision(15), scale(0) of the NUMERIC. This problem has been fixed.

CREATE TABLE tb2 (a NUMERIC (4,4));

PREPARE STMT FROM 'INSERT INTO tb2 VALUES (?)';
EXECUTE STMT USING 0.1;

SELECT a FROM tb2;
    a
==========
    0.0
EXECUTE STMT USING 0.5;
ERROR: A domain conflict exists on attribute "a".

Error when executing CASE or DECODE statements with a PREPARE statement (CUBRIDSUS-11060)

Fix a problem in which query execution failed with the message "ERROR: Semantic: System error (generate var) in ../../src/parser/xasl_generation.c" when a type was not able to be determined, for example, because all the arguments were given as a host variable, in the execution of the CASE or DECODE statements with a PREPARE statement.

PREPARE ST FROM 'SELECT CASE WHEN col=? THEN ? ELSE ? END FROM tbl;'

Error when an INSERT INTO ... SELECT ? ... query was executed while binding INT type in a CHAR type column (CUBRIDSUS-9293)

Fixed a problem in which query execution failed with the message "ERROR: A domain conflict exists on attribute noname" when binding INT type in a CHAR type column when the INSERT INTO ... SELECT ? FROM db_root query was executed.

CREATE TABLE t ( a CHAR(1));
PREPARE s FROM 'INSERT INTO t SELECT ? FROM db_root';
EXECUTE s USING 1;

Problem using the unchanged table to execute a query for a view after changing the name of the table used for creating the view(CUBRIDSUS-8536)

The unchanged table was used to execute a query for the view after changing the name of the table used for creating the view. This problem has been fixed.

CREATE TABLE foo (a INTEGER PRIMARY KEY, b VARCHAR (20));
INSERT INTO foo VALUES (1, 'foo');

CREATE TABLE bar (a INTEGER PRIMARY KEY, b VARCHAR (20));
INSERT INTO bar VALUES (1, 'bar');
CREATE VIEW v1 (a INTEGER, b VARCHAR (20)) AS SELECT * FROM foo;

-- Change the name from foo to foo_old and from bar to foo.
RENAME foo AS foo_old;
RENAME bar AS foo;

-- In the previous versions, 'bar' was output as a result of Q1 and 'foo' as a result of Q2. In version 9.1, 'bar' is output for both.
SELECT b FROM foo; -- Q1
SELECT b FROM v1;  -- Q2

An error occurred when the size of the front VARCHAR type column was smaller than the size of the rear in the UNION query(CUBRIDSUS-9292)

In the UNION query, when the size of the front VARCHAR type column is smaller than the size of the rear, "ERROR: Execute: Query execution failure #1336." error message was displayed and the query execution failed. This problem has been fixed.

CREATE TABLE u1 (a VARCHAR (1));
CREATE TABLE u2 (a VARCHAR (2));
INSERT INTO u1 VALUES ('1');
INSERT INTO u2 VALUES ('22');

SELECT a FROM (SELECT a FROM u1 UNION ALL SELECT a FROM u2) t(a);

An error occurred when the last argument of the CASE .. WHEN clause without the ELSE clause in the PREPARE statement or the last argument of the DECODE function without the DEFAULT argument was the host variable(CUBRIDSUS-10405)

In the previous versions, when the ELSE clause was not specified in the CASE .. WHEN clause and the argument of the last THEN clause was the host variable, an error occurred. This problem has been fixed.

PREPARE st FROM 'select CASE ? WHEN 1 THEN 1 WHEN -1 THEN ? END';
EXECUTE st USING -1, 3;

ERROR: Cannot coerce value of domain "integer" to domain "*NULL*".

In the previous versions, when the DEFAULT argument was not included in the DECODE function and the result argument was the host variable, an error occurred. This problem has been fixed.

PREPARE st FROM 'select DECODE (?, 1, 10,-1,?)';
EXECUTE st USING -1,-10;

ERROR: Cannot coerce value of domain "integer" to domain "*NULL*".

An application was abnormally terminated in the SELECT statement that output the LOB file path when the LOB file name including the absolute path was larger than 128(CUBRIDSUS-10856)

An application was abnormally terminated in the SELECT statement that output the LOB file (the file that saved the actual LOB type data) path when the LOB file name including the absolute path was larger than 128. This problem has been fixed.

CREATE TABLE clob_tbl(c1 clob);
SELECT * FROM clob_tbl;

An application was abnormally terminated when the table set was SELECTed, including view(CUBRIDSUS-11016)

CREATE TABLE t (a int, b int);
CREATE TABLE u (a int, b int);
CREATE VIEW vt AS SELECT * FROM t;

SELECT * FROM (vt, u);

An error recurred to the query of the corresponding same prepare statement when the value of the system parameter max_plan_cache_entries was -1 and an error occurred in executing the INSERT query(CUBRIDSUS-11038)

Issue existed where, while the system parameter max_plan_cache_entries is -1 (plan cache OFF) and an error occurred in the first INSERT query execution, the query that corresponded to the same prepare statement caused continuous errors even if the host variable to bind was changed. This problem has been fixed.

An error occurred when RENAME the table name and DROP the existing table in the query statement that did not use the query plan cache(CUBRIDSUS-11039)

When the system parameter max_plan_cache_entries was configured to -1 and no query plan cache was used or when a host variable was used in the IN clause, the table name was RENAME and then the existing table was DROP in the query statement that did not use the query plan cache. When the query was executed, "INTERNAL ERROR: Assertion 'false' failed" error occurred. This problem has been fixed.

T1 T2
SELECT * FROM foo WHERE id IN (?, ?);  
  CREATE TABLE foo_n AS SELECT * FROM foo;
RENAME foo AS foo_drop;
RENAME foo_n AS foo;
DROP TABLE foo_drop;
SELECT * FROM foo WHERE id IN (?, ?);  

An application was abnormally terminated when the plan cache was OFF and a specific multiple query statement was executed(CUBRIDSUS-11055)

When the max_plan_cache_entries in cubrid.conf was configured to -1 to make the plan cache OFF and then the multiple query statement was executed, the application was abnormally terminated. This problem has been fixed.

An application was abnormally terminated when a query including the comparison statement requiring type conversion attempted to execute(CUBRIDSUS-11064)

When a query including the comparison statement requiring type conversion attempted to execute, the application was abnormally terminated. This problem has been fixed. In the previous versions, it occurred when a function used in the SELECT LIST and the LIMIT clause was used. When either of the two was omitted, the error message was normally output.

SELECT MIN(col_int)
FROM cc
WHERE cc. col_int_key >= 'vf'
LIMIT 1;

Wrong result was output when the SELECT statement that had scanned the index was executed while DESC had been included in a certain column of the multi-column index and the next column value had been NULL(CUBRIDSUS-11354)

CREATE TABLE foo ( a integer primary key, b integer, c integer, d datetime );
CREATE INDEX foo_a_b_d_c on foo ( a , b desc , c );
INSERT INTO foo VALUES ( 1, 3, NULL, SYSDATETIME );
INSERT INTO foo VALUES ( 2, 3, NULL, SYSDATETIME );
INSERT INTO foo VALUES ( 3, 3, 1, SYSDATETIME );

SELECT * FROM foo WHERE a = 1 AND b > 3 ;
-- In the previous version, above query shows a wrong result.

            a            b            c  d
======================================================================
            1            3         NULL  12:23:56.832 PM 05/30/2013

Wrong result was output when column of ORDER BY clause did not exist in the SELECT list of subquery(CUBRIDSUS-11814)

Wrong result was output when column of ORDER BY clause did not exist in the SELECT list of subquery. This problem has been fixed.

SELECT a FROM foo WHERE a IN (SELECT a FROM foo WHERE b = 'AAA' ORDER BY b, c);

A hierarchical query on joined tables, that also contains some correlated subqueries in SELECT list, may lead to wrong result(CUBRIDSUS-11658)

CREATE TABLE t1(i INT);
CREATE TABLE t2(i INT);
INSERT t1 VALUES (1);
INSERT t2 VALUES (1),(2);

SELECT (SELECT COUNT(*) FROM t1 WHERE t1.i=t2.i) FROM t1,t2 START WITH t2.i=1 CONNECT BY NOCYCLE 1=1;

The previous versions returns wrong result.

1
1

The fixed version returns the correct result.

1
0

Number of query results was incorrect for the hierarchical query that included ROWNUM condition and used index(CUBRIDSUS-9531)

The number of query results could not be limited by ROWNUM for the hierarchical query that included ROWNUM condition and used index. This problem has been fixed.

SELECT oid
FROM foo
WHERE ROWNUM = 1
START WITH oid = '1234567'
CONNECT BY PRIOR poid = oid

Wrong result was returned when the first column of the table where the CHAR type columns had been sequentially defined was entered in the CONV function(CUBRIDSUS-11824)

The CONV value for the second column was returned when the first column of the table where the CHAR type columns had been sequentially defined was entered in the CONV function. This problem has been fixed.

CREATE TABLE tbl (h1 CHAR(1), p1 CHAR(4));
INSERT INTO tbl (h1, p1) VALUES ('0', '0001');
SELECT CONV (h1, 16, 10) from tbl;

1

When there is an type casting because types between SELECT list and INSERT list are different in INSERT ... SELECT syntax, and ORDER BY clause exists in SELECT query, INSERTed order became different(CUBRIDSUS-12031)

Fix the case that when there is an type casting because types between SELECT list and INSERT list are different in INSERT ... SELECT syntax, and ORDER BY clause exists in SELECT query, INSERTed order became different.

If an AUTO_INCREMENT column exists in the INSERT list columns, INSERTed order becomes important.

CREATE TABLE t1 (id INT AUTO_INCREMENT, a CHAR(5), b CHAR(5), c INT);
CREATE TABLE t2 (a CHAR(30), b CHAR(30), c INT);
INSERT INTO t2 VALUES ('000000001', '5', 1),('000000002','4',2),('000000003','3',3),('000000004','2',4),('000000005','1',5);
INSERT INTO t1(a,b,c) SELECT * FROM t2 ORDER BY a, b DESC;
SELECT * FROM t1;

Fix to use an index when a subquery is given in a START WITH clause as a condition in a hierarchical query(CUBRIDSUS-9613)

SELECT /*+ RECOMPILE use_idx*/ a, b
FROM foo
START WITH a IN ( SELECT a FROM foo1 )
CONNECT BY PRIOR a = b;

HA

A schema is replicated to the slave node with the user who connected to the DB firstly from the application(CUBRIDSUS-11878)

Schema is replicated to the slave node with the user who had connected to the DB firstly from the application. For example, when user1 account had connected to and disconnected from the DB and then user2 account connected to create a table, the table owned by user1 was created in the slave node. This problem would persist until the Broker Common Application Server (CAS) was restarted. This problem has been fixed.

Add log information for changing the node status(CUBRIDSUS-9748)

Add the following log information for changing the node status in HA environment. This information is written in an error log file when the error_log_level system parameter value is the error value or a lower value.

  • The log information of cub_master process is saved in the $CUBRID/log/<hostname>_master.err file as follows:

    HA generic: Send changemode request to the server. (state:1[active], args:[cub_server demodb ], pid:25728).
    HA generic: Receive changemode response from the server. (state:1[active], args:[cub_server demodb ], pid:25728).
    
  • The log information of cub_server process is saved in the $CUBRID/log/server/<db_name>_<date>_<time>.err file as follows:

    Server HA mode is changed from 'to-be-active' to 'active'.
    

Creating an index whose name is a reserved word would not be reflected to the slave node (CUBRIDSUS-9669)

Fix a problem in which creating an index whose name is a reserved word would not be reflected to a slave node with the error message in the HA environment.

CREATE TABLE t2(a INT, b INT, INDEX "none" (a));
Internal system failure: [t2,'create class [t2] ( [a] integer, [b] integer, index none ([a]) ) '] In line 1, column 44 before ' ([a]) ) '

Replication would be made in the incorrect order of columns in the slave node when creating a table through the CREATE .... AS SELECT statement (CUBRIDSUS-9672)

The new version has fixed a problem in which replication would be made in the incorrect order of columns in the slave node when creating a table through the CREATE .... AS SELECT.

// Execute the following in master node
CREATE TABLE t2 (a INT PRIMARY KEY, b INT, c INT)
AS SELECT t1.c AS a, t1.a AS b, t1.b AS c FROM t1;

// The column order was incorrectly replicated in slave node as follows:
CREATE TABLE [t2] ( [a] INTEGER, [b] INTEGER, [c] INTEGER, PRIMARY KEY ([a]) )
AS SELECT [t1].[c], [t1].[a], [t1].[b] FROM [t1];

Creating a DESC INDEX to a PREFIX column would not be reflected to a slave node (CUBRIDSUS-9674)

Fix a problem in which creating DESC INDEX to a PREFIX column would not be reflected to a slave node in the HA environment.

ALTER TABLE c2 ADD INDEX i_c (c(5) DESC);

Partitioning a table through an ALTER statement would not be reflected to a slave node (CUBRIDSUS-9675)

Fix a problem in which partitioning a table through an ALTER statement would not be reflected to a slave node in the HA environment.

ALTER TABLE range_tbl
REORGANIZE PARTITION p2 INTO
( PARTITION p3 VALUES LESS THAN (25), PARTITION p4 VALUES LESS THAN (30));

ALTER SERIAL statement would not be reflected to a slave node (CUBRIDSUS-9916)

The new version has fixed a problem in which the ALTER SERIAL statement would not be reflected to a slave node in the HA environment.

ALTER SERIAL s1 START WITH 2;

The owner of triggers, serials, stored functions and procedures would be reflected to a slave node incorrectly (CUBRIDSUS-10713)

The new version has fixed a problem in which the owner of triggers, serials, stored functions and procedures would be reflected to a slave node incorrectly as "DBA."

Not to be replicated when the default key configured with multiple columns included the DESC direction(CUBRIDSUS-9774)

CREATE TABLE t (a INTEGER, b INTEGER, c INTEGER, PRIMARY KEY (a, b DESC, c));
INSERT INTO t VALUES (1, 1, 1);

Improve replication rebuilding script(CUBRIDSUS-10327)

Fix to create the $repl_log_home directory set when it was not in the ha_make_slavedb.sh script. Also fixed the problem that caused a replication log of the master node, previously copied from the slave node, to not be deleted while the script was being executed if $CUBRID_DATABASES was different from $repl_log_home.

Not recognizing the last host name when there were several host names set in databases.txt(CUBRIDSUS-10344)

In the HA environment, if there were several host names set in the databases.txt file and the last host name was a string that included the first host name, the last host name would not be recognized correctly. This problem has been fixed. For example, in the previous versions, if the host name list was set to "node:node1", node1 was not recognized correctly. So, when "node" is the slave node and the "node1" is the master node, the RW Broker Common Application Server (CAS) cannot recognize and connect to "node1".

Error log was recorded although the ETIMEOUT error is a normal action in the server process connected to the transaction replication log copying process operated in the ASYNC mode (CUBRIDSUS-10832)

The new version has modified error logs not to be recorded when the "pthread_cond_wait() failed." (ETIMEOUT) occurred in the server process connected to the transaction replication log copying process operated in the ASYNC mode.

An ETIMEOUT error occur when the thread which records transaction logs in the server process exceeds the operation waiting time, and although this error in the ASYNC mode is normal, the previous version recorded this to the error log file, causing disk I/O unnecessarily.

DB server stopped because copylogdb did not respond(CUBRIDSUS-11145)

A DB server hang error that occurred when the connected copylogdb process did not respond has been fixed. When the error occurs, the DB server disconnects from the copylogdb and outputs the following message:

Time: 06/11/13 10:56:40.002 - ERROR *** file ../../src/transaction/log_writer.c, line 1982 ERROR CODE = -1026 Tran = 2, CLIENT = hostname:copylogdb(6694), EID = 110
Timed out waiting for next request from client.

UPDATE and DELETE of the table were not applied to the slave node when UNIQUE and PRIMARY KEY were simultaneously specified(CUBRIDSUS-9676)

When UNIQUE was specified for a column and then PRIMARY KEY was simultaneously specified for the column, UPDATE and DELETE for the table were not applied to the slave node. This problem has been fixed.

CREATE TABLE demo(id INT);
ALTER TABLE demo ADD CONSTRAINT UNIQUE(id);
ALTER TABLE demo ADD CONSTRAINT PRIMARY KEY(id);

Table was not replicated to the slave node when there was the BIGINT type in the partitioned table(CUBRIDSUS-9697)

CREATE TABLE t1 (i1 INTEGER PRIMARY KEY, b BIGINT ) PARTITION BY RANGE ( b )
(
    PARTITION p0 VALUES LESS THAN (1000) ,
    PARTITION p1 VALUES LESS THAN (10000000)
);

applylogdb process or copylogdb process could not connect to the DB server when as much as max_clients connections were established(CUBRIDSUS-10328)

In the HA environment, when as much as max_clients connections were established, applylogdb process or copylogdb process could not connect to the DB server and it failed to execute HA running command. This problem has been fixed.

Health check message was continuously sent to the broker that had been determined normal(CUBRIDSUS-10817)

By the rctime configuration of the connection URL, the health check message was sent to a broker once per minute in the HA environment. If a broker had been included in the failure list once, even if it had been determined to be normal, the health check message was continuously sent to the broker. This problem has been fixed.

Replication reflection was not retried even when retry was required(CUBRIDSUS-10833)

An error of replication reflection not being retried even when retry was configured in ha_applylogdb_retry_error_list in cubrid_ha.conf has been fixed.

An error was returned when the JOB QUEUE of a broker was full without reconnection with altHosts being tried(CUBRIDSUS-10851)

When there were too many requests from applications and the JOB QUEUE of a broker was full, reconnection with altHosts was not tried but the CAS_ER_FREE_SERVER error was returned even though altHosts was specified in the connection URL. This problem has been fixed.

Next transaction could not proceed when log copy was blocked, even though ASYNC was configured in the master node(CUBRIDSUS-10991)

The next transaction could not proceed when log copy was blocked, even though ha_copy_sync_mode in cubrid_ha.conf was configured to ASYNC in the master node. This problem has been fixed.

Add a counterpart node name in the applylogdb error message outputting the server status of the counterpart node(CUBRIDSUS-10992)

A counterpart node name was not included in the applylogdb error message outputting server status of the counterpart node; it is now added.

// before
HA generic: change HA server state from from 'idle' to 'active'..

// after
HA generic: change the state of HA server (testdb@cdbs037.cub) from 'idle' to 'active'.

A view with the BIGINT type column could not be replicated(CUBRIDSUS-11200)

CREATE VIEW vw AS SELECT CAST(2 AS BIGINT) FROM db_root;

Sharding

Abnormal termination of the command which output the metadata of SHARD when executing the command(CUBRIDSUS-10375)

While executing multiple shard proxies by setting the MAX_NUM_PROXY parameter of shard.conf to 2 or the larger value, when the command which output the metadata of CUBRID SHARD was executed using "cubrid shard status -m", the command would be abnormally terminated. This problem has been fixed.

Correct the PROXY_LOG_FILE included in the default setting of shard.conf to PROXY_LOG_DIR(CUBRIDSUS-10381)

Correct the incorrect PROXY_LOG_FILE parameter setting which has been included in the default shard.conf file to PROXY_LOG_DIR.

Fix to handle as an error when the binding array shard key value was in different shards(CUBRIDSUS-9826)

In the Shard environment, if the shard key value of the array to be bound by the functions, such as JDBC PreparedStatement.executeBatch() and CCI cci_execute_array(), which bind several values to process queries at once, is in different shards, the function is handled as an error.

No Response when receiving many prepare requests (CUBRIDSUS-10041)

When there are many prepare requests for a query in the Shard environment, if one of the request has not been processed within the query timeout or PROXY_TIMEOUT, the remaining prepare requests were not responded to. This problem has been fixed.

In shard proxy, even if rcTime of connection URL is specified, the behavior to return to the original connection did not occur(CUBRIDSUS-10823)

Fix a problem that the connection didn't return to the original one after the rcTime(rcTime is specified in ocnnection URL) when shard proxy is failed over.

SHARD CAS SQL log replaces it to the SHARD_ID hint when the SHARD_VAL hint is entered in the query statement(CUBRIDSUS-7156)

When the SHARD_VAL hint is entered in the query statement, the SQL statement written in the SHARD CAS SQL log replaces it to the SHARD_ID hint.

Add an error code to determine the error status when a client cannot access as a SHARD proxy due to the MAX_CLIENT constraint in shard.conf(CUBRIDSUS-8326)

In the previous versions, when a client could not access as a SHARD proxy due to the MAX_CLIENT constraint in shard.conf, the network connection was simply disconnected and the error could not be figured out. It has been fixed to return the error code to determine the error status.

Proxy refused client connection. max clients exceeded

The CAS connection error was processed before the response to transaction commit was processed when SHARD CAS restarted due to limitation in the number of statements or the memory capacity(CUBRIDSUS-10792)

When SHARD CAS restarted due to limitation in the number of statements or the memory capacity, the CAS connection error (Cannot communicate with server) was processed before the application received the response to the transaction commit. This problem has been fixed.

Fix to occur an error when SHARD is running in the Linux system, if the "ulimit -n" value of the system is smaller than the number of required fd(CUBRIDSUS-10837)

Fix the application hang malfunction when the "ulimit -n" value of the system was smaller than the number of required file descriptors (fd) to execute the "cubrid shard start" has been fixed to occur an error. The number of required fd for the Linux system is the sum of the proper numbers to the MAX_CLIENT configured in shard.conf.

CAS status output by the "shard status" command was always IDLE(CUBRIDSUS-10876)

Even when the CAS status output by the "cubrid shard status" command should be changed, it was always output as IDLE. This problem has been fixed.

An error occurred while the application processed the first query after the "shard reset" command(CUBRIDSUS-10895)

When a connection between the SHARD CAS and the DB server process was terminated due to the restart of the DB server process, the "cubrid shard reset" command should be executed for reconnection and all queries should be processed normally; however, an error occurred in the first query processed by the application. This problem has been fixed.

The allocated share memory was too large when executing the "shard start" command(CUBRIDSUS-10954)

The share memory used to execute the "cubrid shard start" command was allocated larger than the required memory, causing waste of memory. This problem has been fixed.

Restarted SHARD CAS could not be used(CUBRIDSUS-11271)

When the SHARD CAS was frequently restarted due to the increased memory, the SHARD CAS could not receive the user request. This problem has been fixed.

The recent request time of the application was not updated when executing the "shard status -c" command(CUBRIDSUS-11272)

When executing the "shard status -c" command, the recent request time (L-REQ-TIME) of the application that was output was not updated. This has been fixed to update always.

In addition, the titles of a column output when the command is executed, L-REQ-TIME and L-RES-TIME, are changed to LAST-REQ-TIME and LAST-RES-TIME.

Number of CASs for the SHARD proxy is managed dynamically(CUBRIDSUS-10130)

In shard.conf, the minimum number of the CAS (MIN_NUM_APPL_SERVER) for the SHARD proxy system should be configured as same with the maximum number (MAX_NUM_APPL_SERVER). It has been fixed to configure the two differently to increase or decrease the number of CAS processes according to the configuration and the load.

In addition, the STMT-Q and the SHARD-Q information is output when the "cubrid shard status -b" command is executed.

$ cubrid shard status -b -s 1 -t
@ cubrid shard status

  NAME           PID  PORT   Active-P   Active-C  STMT-Q SHARD-Q  TPS  QPS   SELECT   INSERT   UPDATE   DELETE   OTHERS   K-QPS  NK-QPS     LONG-T     LONG-Q   ERR-Q  UNIQUE-ERR-Q  #CONNECT
==============================================================================================================================================================================================
* shard1       18046 45511          4         16       0      12   56   65        0        0        0        0        0      65       0     0/60.0     0/60.0       0             0         0
  • STMT-Q: The number of requests from a client that is waiting to execute prepare at the time of executing the shard status command
  • SHARD-Q: The number of requests from a client that is waiting for available CAS at the time of executing the shard status command

In Linux, the number of clients that can be connected to a SHARD proxy process is up to 10,000(CUBRIDSUS-10218)

In Linux, the number of clients that could be connected to a SHARD proxy process was limited to 500. It has been fixed up to 10,000.

  • The number of file descriptors (fd) used for one SHARD proxy process is as follows: "((MAX_CLIENT + MAX_NUM_APPL_SERVER) / MAX_NUM_PROXY) + 256"

Driver

[JDBC][CCI] Improved query timeout calculation (CUBRIDSUS-9585)

The query timeout period has been modified to stop query execution when the query timeout period requested by the application has expired, by sending the time remaining to the server.

[JDBC][CCI] Phenomenon that would cause query timeout and failure to occur in the middle of fetch when query timeout has been set(CUBRIDSUS-9043)

When query timeout was set using the broker parameter MAX_QUERY_TIMEOUT, JDBC's setQueryTimeout method, and the queryTimeout attribute of the connecting URL, query timeout would occur in the middle of fetch, and a failure would also occur. This has been fixed, and now no query timeout occurs in the middle of fetch. The timeout occurs only when the query is being executed.

In addition, query timeout does not occur for the cci_execute_batch function and the cci_execute_array function.

[JDBC][CCI] Now the remaining queries are not executed when deadlock occurs while an array/batch execution function executes queries(CUBRIDSUS-9692)

In the previous versions, when a deadlock occurred while an array/batch execution functions, such as JDBC's PreparedStatement.executeBatch method or CCI's cci_execute_array and cci_execute_batch, were executing each query statement, the remaining queries would be continuously executed. This has been fixed, and now the remaining queries are no longer executed when deadlock occurs. For other general errors, the remaining queries are continuously executed.

[JDBC][CCI] DB server process was abnormally terminated when a driver lower than 2008 R4.0 and a driver of 2008 R4.0 or higher were used together(CUBRIDSUS-10916)

When a driver lower than 2008 R4.0 and a driver of 2008 R4.0 or higher were used together, CHANGE CLIENT occurred and the same SESSION ID was duplicated, causing abnormal termination of the DB server process. This problem has been fixed.

[JDBC] Fix to output a variety of information in the message when an exception occurs(CUBRIDSUS-9611)

Fix to output the Broker Common Application Server (CAS) ID, CAS PID, SESSION ID, and connection URL in the message when an exception occurs in JDBC.

[JDBC] Exception when calling PreparedStatement.clearParameter() method even when the application has not closed the statement(CUBRIDSUS-10274)

An exception 'Connection or Statement might be closed' would occur when the PreparedStatement.clearParameter() method was called while the user did not disconnect the DB connection and closed the statement in the JDBC application. This problem has been fixed.

[JDBC] ResultSetMetaData.isAutoIncrement() method would not operate normally (CUBRIDSUS-9710)

Previously, when the ResultSetMetaData.isAutoIncrement() of JDBC was called , FALSE was returned regardless of whether AUTO_INCREMENT was set. Now it operates properly according to the configuration of AUTO_INCREMENT.

[JDBC] Reconnection to altHosts was not tried even when connectTimeout was configured in the connection URL(CUBRIDSUS-10240)

Fix error occurring when connectTimeout was configured in URL from JDBC and altHosts reconnection by connectTimeout was not tried.

[JDBC] A wrong exception error was returned when the closed object was accessed(CUBRIDSUS-7251)

When the JDBC application accessed the object that had been already closed, such as java.sql.ResultSet, java.sql.Statement, java.sql.PreparedStatement, java.sql.CallableStatement, java.sql.Connection, and java.sql.DatabaseMetaData object, the SQLException exception error should have returned; however, the NullPointerException exception error was returned. This problem has been fixed.

[JDBC] A wrong error message was output when the zeroDateTimeBehavior property of the connection URL was configured to exception and the zero date was retrieved(CUBRIDSUS-9963)

In the JDBC application, when the zeroDateTimeBehavior property of the connection URL was configured to exception and the zero date was retrieved, a wrong error message was output. This problem has been fixed to output a normal error message.

// before message
invalid argument

// after message
Zero date can not be represented as java.sql.Timestamp.

For reference, in the 2008 R4.0 or lower versions, TIMESTAMP '1970-01-01 00:00:00'(GMT) is the minimum value of TIMESTAMP; however, in the 2008 4.1 or higher versions, it is recognized as zerodate and TIMESTAMP '1970-01-01 00:00:01'(GMT) is the minimum value of TIMESTAMP.

[JDBC] Query timeout error occurred in the query statement that should normally be executed when the queryTimeout was configured to a very large value(CUBRIDSUS-10967)

Fix abnormal query timeout error in the JDBC application when the queryTimeout was configured to a very large value. In addition, queryTimeout is limited to 2,000,000.

[CCI] -20004 error when prepared statement is performed(CUBRIDSUS-10937)

Fixed a problem that -20004 error(CCI_ER_COMMUNICATION) occurred when a driver retried "prepare" operation and CAS was restarted simultaneously; "prepare" retrial is performed if CAS_ER_STMT_POOLING error occurred during running cci_execute() with autocommit mode ON.

[CCI] Incorrect information about in which column an index was created was outputted when fetching the result of the execution of cci_schema_info() (CUBRIDSUS-9689)

Fix a problem in which incorrect values with regard to in which column an index was created were outputted when fetching the result of the execution of cci_schema_info().

[CCI] CAS_NO_MORE_DATA Error when completing fetch after executing the SELECT query in asynchronous mode(CUBRIDSUS-7170)

The CAS_NO_MORE_DATA error would occur when completing fetch after executing the SELECT query in asynchronous mode, instead of the CCI_NO_MORE_DATA error. This problem has been fixed.

res = cci_execute (req, CCI_EXEC_ASYNC, 0, &error);

[CCI] Abnormal operation of application when the closed connection was reused in DATASOURCE(CUBRIDSUS-9586)

The application operated abnormally when the CCI application reused the closed DATASOURCE connection. This has been fixed to output an error.

con_1 = cci_datasource_borrow (ds, &error);
cci_prepare_and_execute (con_1, query, 1, &exec_retval, &error);
ret = cci_datasource_release (ds, con_1, &error);

ret = cci_prepare_and_execute (con_1, query, 1, &exec_retval, &error); /* invalid access */

[CCI] Abnormal termination of application when calling cci_execute() after calling cci_datasource_release() with setting pool_prepared_statement property=OFF(CUBRIDSUS-10847)

Fix a problem that an application was abnormally terminated when calling cci_execute() after calling cci_datasource_release() with setting pool_prepared_statement property=OFF.

[CCI] Error when calling the cci_execute function twice as executing multiple query statements by using the function(CUBRIDSUS-10424)

If the first query type was different from the last query type when executing multiple query statements using the cci_execute function, e.g., the first one is the UPDATE statement and the last one is the SELECT statement, the "Invalid cursor position" error would occur when the function was called twice. This problem has been fixed.

static char *MULTI_STMT = "UPDATE T1 SET B = A; SELECT A FROM T1 WHERE A = ?;";

result = cci_execute (request, CCI_EXEC_QUERY_ALL, 0, error); /* 1st */

result = cci_execute (request, CCI_EXEC_QUERY_ALL, 0, error); /* 2nd */

[CCI] Not linked when using the static library(CUBRIDSUS-10743)

Fix a problem that a link error occurs when C code is compiled.

[CCI] An incorrect error message was included in the error buffer of the cci_connect_with_url_ex function(CUBRIDSUS-10234)

When an error occurred in the cci_connect_with_url_ex function, "DBMS Error" was saved in the error buffer instead of the correct message. This problem has been fixed. For example, when a wrong password is entered, the "Incorrect or missing password" error message should be saved.

[CCI] An error occurred after successful cci_datasource_borrow call when the connection was used(CUBRIDSUS-11159)

In the environment that multiple applications use the CCI datasource, when they succeed in calling the cci_datasource_borrow and try to use the connection, an error occurred. This problem has been fixed.

[CCI] An error occurred when the next query was executed if the cci_datasource_release function was called and rollback of the transaction being executed failed(CUBRIDSUS-11841)

When the cci_datasource_release function was called while the transaction had not been terminated, the transaction was rolled back. When the rollback failed, the transaction status of the driver was not changed to Complete but kept as in transaction, causing an error in the next query execution. This problem has been fixed.

[CCI] Add omitted error messages for the error codes(CUBRIDSUS-11217)(CUBRIDSUS-11310)

The omitted error messages for error codes including CCI_ER_NO_PROPERTY, CCI_ER_PROPERTY_TYPE, CCI_ER_INVALID_DATASOURCE, CCI_ER_DATASOURCE_TIMEOUT, CCI_ER_DATASOURCE_TIMEDWAIT, CCI_ER_LOGIN_TIMEOUT and CCI_ER_QUERY_TIMEOUT are added.

Administrative Convenience

The NOTIFICATION message is output in the error log file to notify the start and the end of log recovery when the DB server is started or the backup volume is restored(CUBRIDSUS-9620)

When the DB server is started or the backup volume is restored, the NOTIFICATION message for the start time and the end time of log recovery is output in the error log file or the restoredb error log file. In the start log, the number of logs to redo and the number of log pages are written. The time required for the task can be checked from the log.

Time: 06/14/13 21:29:04.059 - NOTIFICATION *** file ../../src/transaction/log_recovery.c, line 748 CODE = -1128 Tran = -1, EID = 1
Log recovery is started. The number of log records to be applied: 96916. Log page: 343 ~ 5104.
.....
Time: 06/14/13 21:29:05.170 - NOTIFICATION *** file ../../src/transaction/log_recovery.c, line 843 CODE = -1129 Tran = -1, EID = 4
Log recovery is finished.

The query statement is written as a NOTIFICATION error message when the server fails to execute a query(CUBRIDSUS-10665)

When the server fails to execute a query, the query statement is written as a NOTIFICATION error message as shown below.

Time: 06/13/13 18:34:27.395 - NOTIFICATION *** file ../../src/communication/network_interface_sr.c, line 5803 CODE = -1122 Tran = 1, CLIENT = cdbs035.cub:query_editor_cub_cas_1(20781), EID = 7
Query execution error. ERROR_CODE = -670, /* SQL_ID: 9759b7e11189b */ update t1 set a=1 where a>?

The connection failure information is written in the CAS SQL log when the CAS cannot access the DB(CUBRIDSUS-10676)

If the CAS cannot access the DB because of incorrect password or other reasons, the connection failure information is written in the CAS SQL log under $CUBRID/log/broker/sql_log. The following information which was not included before the update is written additionally after the update.

13-05-29 11:02:54.172 (0) connect db bug_7455 user dba url cci:cubrid:10.24.18.66:38000:bug_7455:dba:********: - error:-171(Incorrect or missing password.)

The NOTIFICATION message is output in the server error log when the statistical information update is started and ended(CUBRIDSUS-10702)

When the statistical information update is started and ended, the NOTIFICATION message is output in the server error log. You can check the time required for updating the statistical information from the log.

Time: 05/07/13 15:06:25.052 - NOTIFICATION *** file ../../src/storage/statistics_sr.c, line 123 CODE = -1114 Tran = 1, CLIENT = testhost:csql(21060), EID = 4
Started to update statistics (class "code", oid : 0|522|3).

Time: 05/07/13 15:06:25.053 - NOTIFICATION *** file ../../src/storage/statistics_sr.c, line 330 CODE = -1115 Tran = 1, CLIENT = testhost:csql(21060), EID = 5
Finished to update statistics (class "code", oid : 0|522|3, error code : 0).

The NOTIFICATION message is output in the server error log when the overflow key or the overflow page occurs(CUBRIDSUS-10703)

When the overflow key or the overflow page occurs, the NOTIFICATION message is output in the server error log. With this message, you can detect that the DB performance becomes slower.

Time: 06/14/13 19:23:40.485 - NOTIFICATION *** file ../../src/storage/btree.c, line 10617 CODE = -1125 Tran = 1, CLIENT = testhost:csql(24670), EID = 6
Created the overflow key file. INDEX idx(B+tree: 0|131|540) ON CLASS hoo(CLASS_OID: 0|522|2). key: 'z ..... '(OID: 0|530|1).
...........

Time: 06/14/13 19:23:41.614 - NOTIFICATION *** file ../../src/storage/btree.c, line 8785 CODE = -1126 Tran = 1, CLIENT = testhost:csql(24670), EID = 9
Created a new overflow page. INDEX i_foo(B+tree: 0|149|580) ON CLASS foo(CLASS_OID: 0|522|3). key: 1(OID: 0|572|578).
...........

Time: 06/14/13 19:23:48.636 - NOTIFICATION *** file ../../src/storage/btree.c, line 5562 CODE = -1127 Tran = 1, CLIENT = testhost:csql(24670), EID = 42
Deleted an empty overflow page. INDEX i_foo(B+tree: 0|149|580) ON CLASS foo(CLASS_OID: 0|522|3). key: 1(OID: 0|572|192).

When load is concentrated and a specific server thread fails to access the page for UPDATE several times, the detailed error message is output(CUBRIDSUS-10704)

When load was concentrated and a specific server thread failed to access the page for UPDATE several times, the "Internal system failure: No more specific information is available." error occurred. However, for more detailed information, the "LATCH ON PAGE(xx|xx) ABORTED" message is output.

Add function and log messages so that they can be checked through the CAS information at the driver(CUBRIDSUS-10818)

To check the CAS information at the driver, the cci_get_cas_info function of CCI or the Connection.toString() method of JDBC are provided. In addition, the CAS information is included in the slow query log of the driver and the error message.

The following example shows how to display the CAS information in the JDBC application by using the toString() method of the cubrid.jdbc.driver.CUBRIDConnection class.

cubrid.jdbc.driver.CUBRIDConnection(CAS ID : 1, PROCESS ID : 22922)

The following example shows how to display the CAS information in the CCI application by using the cci_get_cas_info() function.

127.0.0.1:33000,1,12916

The slow query log of the JDBC driver includes the CAS information as shown below.

2013-05-09 16:25:08.831|INFO|SLOW QUERY
[CAS INFO]
localhost:33000, 1, 12916
[TIME]
START: 2013-05-09 16:25:08.775, ELAPSED: 52
[SQL]
SELECT * from db_class a, db_class b

The slow query log of the CCI includes the CAS information as shown below.

2013-05-10 18:11:23.023 [TID:14346] [DEBUG][CONHANDLE - 0002][CAS INFO - 127.0.0.1:33000, 1, 12916] [SLOW QUERY - ELAPSED : 45] [SQL - select * from db_class a, db_class b]

The error message of the JDBC includes the CAS information as shown below.

Syntax: syntax error, unexpected IdName [CAS INFO - localhost:33000,1,30560],[SESSION-16],[URL-jdbc:cubrid:localhost:33000:demodb::********:?logFile=driver_1.log&logSlowQueries=true&slowQueryThresholdMillis=5].

The error message of the CCI includes the CAS information as shown below.

Syntax: syntax error, unexpected IdName [CAS INFO - 127.0.0.1:33000, 1, 30560].

Version information of the connected driver is included in the SQL log or the status information of the broker(CUBRIDSUS-10936)

The version information of the connected driver is included in the SQL log or the status information of the broker output by executing the "cubrid broker status -f" command.

In the updated version, the SQL log is output as follows:

13-05-27 18:50:08.584 (0) CLIENT VERSION 8.4.4.0165

In the updated version, the broker status information is output as follows:

$ cubrid broker status -f
@ cubrid broker status
% test
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   ID PID QPS LQS PSIZE STATUS LAST ACCESS TIME DB HOST LAST CONNECT TIME CLIENT IP CLIENT VERSION SQL_LOG_MODE TRANSACTION STIME #CONNECT #RESTART
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    1 12236 10 0 63820 CLOSE_WAIT 2013/05/12 16:22:51 demodb localhost 2013/05/12 16:22:06 10.64.48.166 8.4.4.0165 - 2013/05/12 16:22:51 8 0
SQL:

Query statement output by executing the killtran command is output as the same string entered by the user(CUBRIDSUS-10251)

When a query statement was output by executing the "cubrid killtran" command, the string output was rewritten by the system. Now, the string is output the same as the string entered by the user.

Utility

In CSQL, the additional information, such as the number of rows the query has affected and the execution time, are displayed in one line(CUBRIDSUS-10055)

In the previous versions, the additional information was displayed in several lines as shown below.

1 rows selected.
SQL statement execution time: 0.008940 sec

Current transaction has been committed.

After the update, it is displayed in one line.

1 rows selected. (0.008940 sec) Committed.

The cause of access failure was not output in the console when failing to access the DB server in CSQL(CUBRIDSUS-10073)

When the CSQL failed to access the DB server, the cause of access failure was written only in the csql.err and only the access failure message was output in the console. This has been fixed to output the cause of access failure in the console as well.

The following error message occurs when the CAS process that exceeds the max_clients configuration value in cubrid.conf is executed:

$ csql testdb@localhost
Server refused client connection: max clients, (10), exceeded.
Failed to connect to database server, 'testdb', on the following host(s): localhost

ERROR: Failed to connect to database server, 'testdb', on the following host(s): localhost

The following error message occurs when the version of the DB server is different from that of the broker:

$ csql testdb@testhost.cub
Server release 8.4.4 is different from client release 9.2.0.
Failed to connect to database server, 'testdb', on the following host(s): testhost.cub

ERROR: Failed to connect to database server, 'testdb', on the following host(s): testhost.cub

CSQL was abnormally terminated when executing a query once more after the termination of the database server (CUBRIDSUS-11634)

Previously, when executing a query in the CSQL Interpreter after terminating the database server, the error message "ERROR: Your transaction has been aborted by the system due to server failure or mode change." was outputted at first but when executing a query again, the CSQL Interpreter was abnormally terminated. This problem has been fixed.

Add CSQL command to limit the length of a column when printing the result(CUBRIDSUS-9643)

Add CSQL session command, which limits the lenght of a column when CSQL interpreter prints the result.

  • ;STring-width limits the length of printing the column of character string or bit string types. In addition, command line option, --string-width is provided.
  • ;COLumn-width limits the length of printing the column without distinguishing types.

Failure of executing ";read", the CSQL session command, when the file name was followed by a space(CUBRIDSUS-10357)

Fix an error that would occur when executing the following command when the name of test.txt was followed by a space.

csql> ;read test.txt
ERROR: Too many file names have been entered.

Annotation not to be processed normally when the annotation included a single quote in CSQL(CUBRIDSUS-9696)

Fix the problem that caused the session command not to be executed because the annotation was not correctly processed in the following case:

csql> -- it's a line comment.
csql> ;exit

Fix to occur an error when a non-existent path is entered in the -D option of the backupdb command(CUBRIDSUS-10642)

When a non-existent path was entered in the -D option of the "cubrid backupdb" command, a malfunction occurred; however, it has been fixed to be processed to occur an error.

Abnormal execution occurred when data of which year had been changed existed in the input file of broker_log_top(CUBRIDSUS-10435)

When the CAS log file, the input file of broker_log_top, had no year information and data with which the year was changed due to this coexisting in one file, it was not normally executed. This problem has been fixed to execute normally if the broker_log_top executes with the log date including the year information (YY-MM-DD).

Fix the errors relating to broker_log_converter and broker_log_runner(CUBRIDSUS-10822)

When the varchar column existed in the bind value, the result file of broker_log_converter had a wrong binding value. When the datetime column existed in the binding value, while executing broker_log_runner the CCI application had the "type conversion" error. These problems have been fixed.

In addition, when the binding value included the datetime column, the date string format of the cci_bind_param was only "YYYY/MM/DD." Now, "YYYY/MM/DD" or "YYYY-MM-DD" is also allowed.

A wrong "Run Deadlock interval" value was output when the cubrid lockdb command was executed(CUBRIDSUS-11798)

A wrong "Run Deadlock interval" value was output when the cubrid lockdb command was executed. This problem has been fixed.

Lock Escalation at = 100000, Run Deadlock interval = -689679844

The connection between the CAS and the broker is immediately reset when the "cubrid broker reset" command is executed(CUBRIDSUS-11972)

In the previous versions, the existing connection between the CAS and the DB server was kept even when the"cubrid broker reset" command was executed. This has been fixed to reset the connection immediately.

backupdb utility of the Windows version to output an internal error for an incorrect input(CUBRIDSUS-10634)

When a directory that did not exist was entered in the -D option of the cubrid backupdb utility for the Windows version, the "pthread_cond_destroy" error would occur. This problem has been fixed.

Query statement terminated by the killtran utility to not return an error(CUBRIDSUS-10133)

When a transaction executing a query was terminated by the killtran utility, no error was returned. This has been fixed to return the "Has been interrupted" error.

Fix to include the original statement of the query when outputting the plandump utility or the slow query log(CUBRIDSUS-9593)

When the query that was a query plan target was output, or a slow query was output in the server error log or the broker log by using the cubrid plandump utility, the rewritten query statement was output in the previous versions. This has been fixed to also output the original query statement entered by the user.

Abnormal termination of the broker_log_top utility when the SQL log file type was wrong(CUBRIDSUS-10072)

Fix the problem that would cause the broker_log_top utility and the shard_broker_log_top utility to be abnormally terminated when the SQL log file type was incorrect.

The number of client wait CASes is larger than the total of CASes when outputting the broker status information(CUBRIDSUS-10235)

When outputting the broker status information using the cubrid broker status -f command, if the number of CASes increased to be higher than the minimum number and then decreased, the number of CLIENT WAIT CASes was larger than the total number of CASes. This problem has been fixed.

Parameter value is set incorrectly when changing the parameter value using the shard_broker_changer utility(CUBRIDSUS-9956)

Fix a problem causing parameter values such as SQL_LOG, SLOW_LOG, and PROXY_LOG to be changed to the wrong values using the shard_broker_changer utility.

Output an incorrect ERR-Q value when the -s option of cubrid broker status command has been set(CUBRIDSUS-10391)

When the -s option of cubrid broker status command was set, the number of error queries per second was output in the ERR-Q item. This has been fixed to output the number of error queries for N seconds as an option.

Improve the error message output when entering the volume size out of the range as creating the DB(CUBRIDSUS-9761)

Fix to output the error message that says that the volume size has been entered in Bytes(B) when the volume size out of the allowable DB size has been entered while creating the DB.

% cubrid createdb testdb --db-volume-size=1121
Couldn't create database.
The given 'db_volume_size', 1121B is out of range. Choose a size between 20.0M and 20.0G.

Problem preventing the checkdb utility execution from being interrupted(CUBRIDSUS-10831)

Fix the problem that prevented the index check task carried out by the cubrid checkdb utility from being interrupted and stopped.

Validation of the page allocation table information of the database volume is performed when checkdb is executed in SA mode(CUBRIDSUS-10755)

At the header of the database volume, the allocation table for the page used by the current volume is kept. When checkdb is executed in the SA mode, a validation check is made to check whether the page allocation table information of each volume is identical with the page information kept by the database.

If not identical, the following error message is written.

Internal error: Page id 256 is allocated according to the allocation map of volume "/home1/cubrid/tdb_x001", but it does not belong to any file.
Internal error: Page id 256 of volume "/home1/cubrid/tdb_x001" is currently being used. But it is not allocated according to the allocation map of volume.

Configuration, Build, and Installation

Maximum number of lines of the IP list per DB user in one broker that allows access to the ACCESS_CONTROL_FILE parameter of the broker is increased to 256(CUBRIDSUS-11985)

The maximum number of lines of an IP list allowed to access the ACCESS_CONTROL_FILE parameter of a broker was 100 for one user per DB. This has been increased to 256 lines.

Normally executed query had been included in the SQL log, even when the broker parameter SQL_LOG has been set to NOTICE(CUBRIDSUS-10286)

Even when the SQL_LOG value of cubrid_broker.conf was set to NOTICE, the query that has been normally executed was often output. The possibility of this occurring has been reduced.

Alarm message based on Java installation while installing the CUBRID engine in Windows(CUBRIDSUS-9917)

If Java 1.6 or higher has not been installed in Windows while installing the CUBRID engine, the message saying that CUBRID Manager could not be used would be output. But this message is not related with the CUBRID engine. Therefore, this has been fixed to output a message saying that the Java stored procedure cannot be used.

Incorrect error message was outputted when executing a broker utility without the cubrid_broker.conf file (CUBRIDSUS-11243)

In the previous version, when starting a broker without the cubrid_broker.conf file, the broker was not started with the abnormal error message "The socket path is too long (>108): /home/CUBRID/var/CUBRID_SOCK/". The new version has been fixed to output a normal error message.

Previously, when executing cubrid broker status and cubrid broker stop without the cubrid_broker.conf file, the incorrect message "cubrid broker is not running." was outputted but this has been fixed to output a correct error message.

/etc/init.d is installed and the cubrid script is added to the chkconfig upon the installation of RPM package(CUBRIDSUS-10657)

When the RPM package is installed, /etc/init.d is installed and the cubrid script is added in chkconfig. When rebooting the system after installation, the "service cubrid start" command is automatically executed. However, in the updated version, the $CUBRID_USER environment variable in the cubrid script file should be changed to the Linux account where the CUBRID has been installed. In the previous versions, the $CUBRID/share/init.d cubrid script was included, and it was required to change the $CUBRID_USER environment variable included in this file to the Linux account where the CUBRID has been installed, and to register the account in the /etc/init.d.

An error occurred when logging in with cshell after the installation of RPM package(CUBRIDSUS-9769)

When the RPM package was installed, the /etc/profile.d/cubrid.csh file was created. The user logging in with cshell met an error when executing the file. This problem has been fixed.

In the versions before 2008 R4.1 Patch 2, wrong data larger than the length of the column was inserted because of a bug, and the data could not be read after upgrade(CUBRIDSUS-10347)

In the versions before 2008 R4.1 Patch 2, a wrong data larger than the length of the column was inserted because of a bug, and the data could not be read after upgrade. The data can now be cut to the length of the column and be read.

In Windows, the tar.gz source compressed file was not successfully decompressed(CUBRIDSUS-10959)

In Windows, the tar.gz source compressed file was not successfully decompressed. This problem has been fixed. In addition, a separate new version provides a zip. file for Windows users.

cub_cmhttpd binary was not built when building with the binary for 64-bit Linux(CUBRIDSUS-10960)

The following error occurred and the cub_cmhttpd binary was not built when building with the binary for a 64-bit Linux.

build_64 command not found

Others

All cursors are closed when there is an internal error in autocommit mode(CUBRIDSUS-10937)

Fix a problem that all holding cursors were closed by auto-rollback when an internal -20004 error(CAS_ER_STMT_POOLING) in autocommit mode occurred.

Fix to write the NOTIFICATION message for the request for database access only once(CUBRIDSUS-9885)

Fix to output only one NOTIFICATION message for the access request to the database server. In the previous versions, two NOTIFICATION messages were output to indicate the start and end of the processing of the request.

-495 error when many clients executed UPDATE for the Same table(CUBRIDSUS-10651)

When many clients simultaneously executed UPDATE for the same table and a query timeout frequently occurred, the -495 error ("Execute: Query execution failure #8560") would occur. This problem has been fixed.

However, when a specific server thread has failed to access a page for update several times due to load being concentrated, a -495 error would occur in the previous version. After the update, the -2 error ("Internal system failure: no more specific information is available.") occurs. This situation may occur when there is a large number of UPDATE requests for the same page within a short period. In this case, the user should retry the failed query.

Wrong memory usage in the CAS Log when the broker common application server (CAS) is restarted due to the exceeded memory usage(CUBRIDSUS-10181)

Fix to output the memory usage of the corresponding process in the CAS log when the Broker Common Application Server (CAS) is restarted due to excessive APPL_SERVER_MAX_SIZE of cubrid_broker.conf, which is the maximum value of the memory usage.

01/10 18:43:42.217 (0) CAS MEMORY USAGE (101M) HAS EXCEEDED MAX SIZE (101M)

Wrong error if cub_master is not started when accessing the server through the broker of Windows version(CUBRIDSUS-10739)

In case that the application accesses the server through the broker of Windows version, the wrong error occurs and CAS runs infinite loop when cub_master process is not started.

In previous version of Windows, below error number will be returned. * On the first trial of access, -21112 (An IOException was caught during reading the inputstream) is returned. * On the second trial of access, -21013 (Cannot connect to a broker) is returned.

In previous and fixed versions of Linux and fixed version of Windows, below error number will be returned. * On the first and second trial of access, -353 (Failed to connect to database server, 'basic', on the following host(s): localhost) will be returned.

Wrong Message that the Broker Has Been Normally Operated Even when the Broker Parameter Value was Incorrect in Windows(CUBRIDSUS-11243)

Fix to output an error message saying that the broker cannot be operated when the broker parameter value is incorrect in Windows.

Incorrect error message was outputted when the broker parameter value was incorrect (CUBRIDSUS-11243)

The new version has fixed a problem in which an inappropriate error message "Error: can't find cubrid_broker.conf" was outputted when the broker parameter value was incorrect.

ER_FILE_TABLE_CORRUPTED error, which occurs while restoring the DB server process from abnormal termination, is changed to WARNING(CUBRIDSUS-10921)

The ER_FILE_TABLE_CORRUPTED error occurred while restoring the DB server process from abnormal termination; however, it is an expected error, and has been changed to WARNING.

Cautions

New Cautions

Change the default value of SQL_LOG_MAX_SIZE broker parameter from 100MB to 10MB(CUBRIDSUS-9944)

From 2008 R4.4, the default value of SQL_LOG_MAX_SIZE of cubrid_broker.conf is changed from 100MB to 10MB. If you want to leave more log information, this value should be set larger.

[JDBC] Change zero date of TIMESTAMP into '1970-01-01 00:00:00'(GST) from '0001-01-01 00:00:00' when the value of zeroDateTimeBehavior in the connection URL is "round"(CUBRIDSUS-11612)

From 2008 R4.4, when the value of the property "zeroDateTimeBehavior" in the connection URL is "round", the zero date value of TIMESTAMP is changed into '1970-01-01 00:00:00'(GST) from '0001-01-01 00:00:00'. You should be cautious when using zero date in your application.

Existing Cautions

Modify how to process an error for the array of the result of executing several queries at once in the CCI application(CUBRIDSUS-9364)

When executing several queries at once in the CCI application, if an error has occurs from at least one query among the results of executing queries by using the cci_execute_array function, the cci_execute_batch function, the error code of the corresponding query was returned from 2008 R3.0 to 2008 R4.1. This problem has been fixed to return the number of the entire queries and check the error of each query by using the CCI_QUERY_RESULT_* macros from 2008 R4.3 and 9.1 version.

In earlier versions of this modification, there is no way to know whether each query in the array is success or failure when an error occurs; therefore, it it requires certain conditions.

...
char *query = "INSERT INTO test_data (id, ndata, cdata, sdata, ldata) VALUES (?, ?, 'A', 'ABCD', 1234)";
...
req = cci_prepare (con, query, 0, &cci_error);
...
error = cci_bind_param_array_size (req, 3);
...
error = cci_bind_param_array (req, 1, CCI_A_TYPE_INT, co_ex, null_ind, CCI_U_TYPE_INT);
...
n_executed = cci_execute_array (req, &result, &cci_error);

if (n_executed < 0)
  {
    printf ("execute error: %d, %s\n", cci_error.err_code, cci_error.err_msg);

    for (i = 1; i <= 3; i++)
      {
        printf ("query %d\n", i);
        printf ("result count = %d\n", CCI_QUERY_RESULT_RESULT (result, i));
        printf ("error message = %s\n", CCI_QUERY_RESULT_ERR_MSG (result, i));
        printf ("statement type = %d\n", CCI_QUERY_RESULT_STMT_TYPE (result, i));
      }
  }
...

From the modified version, entire queries are regarded as failure if an error occurs. In case that no error occurred, it is determined whether each query in the array succeeds or not.

...
char *query = "INSERT INTO test_data (id, ndata, cdata, sdata, ldata) VALUES (?, ?, 'A', 'ABCD', 1234)";
...
req = cci_prepare (con, query, 0, &cci_error);
...
error = cci_bind_param_array_size (req, 3);
...
error = cci_bind_param_array (req, 1, CCI_A_TYPE_INT, co_ex, null_ind, CCI_U_TYPE_INT);
...
n_executed = cci_execute_array (req, &result, &cci_error);
if (n_executed < 0)
  {
    printf ("execute error: %d, %s\n", cci_error.err_code, cci_error.err_msg);
  }
else
  {
    for (i = 1; i <= 3; i++)
      {
        printf ("query %d\n", i);
        printf ("result count = %d\n", CCI_QUERY_RESULT_RESULT (result, i));
        printf ("error message = %s\n", CCI_QUERY_RESULT_ERR_MSG (result, i));
        printf ("statement type = %d\n", CCI_QUERY_RESULT_STMT_TYPE (result, i));
      }
  }
...

Since the 2008 R4.1 version, the Default value of CCI_DEFAULT_AUTOCOMMIT has been ON(CUBRIDSUS-5879)

The default value for the CCI_DEFAULT_AUTOCOMMIT broker parameter, which affects the auto commit mode for applications developed with CCI interface, has been changed to ON since CUBRID 2008 R4.1. As a result of this change, CCI and CCI-based interface (PHP, ODBC, OLE DB etc.) users should check whether or not the application's auto commit mode is suitable for this.

From the 2008 R4.0 version, the options and parameters that use the unit of pages were changed to use the unit of volume size(CUBRIDSUS-5136)

The options (-p, -l, -s), which use page units to specify the database volume size and log volume size of the cubrid createdb utility, will be removed. Instead, the new options, added after 2008 R4.0 Beta (--db-volume-size, --log-volume-size, --db-page-size, --log-page-size), are used.

To specify the database volume size of the cubrid addvoldb utility, use the newly-added option (--db-volume-size) after 2008 R4.0 Beta instead of using the page unit. It is recommended to use the new system parameters in bytes because the page-unit system parameters will be removed. For details on the related system parameters, see the below.

Be cautious when setting db volume size if you are a user of a version before 2008 R4.0 Beta(CUBRIDSUS-4222)

From the 2008 R4.0 Beta version, the default value of data page size and log page size in creating the database was changed from 4 KB to 16 KB. If you specify the database volume to the page count, the byte size of the volume may differ from your expectations. If you did not set any options, 100MB-database volume with 4KB-page size was created in the previous version. However, starting from the 2008 R4.0, 512MB-database volume with 16KB-page size is created.

In addition, the minimum size of the available database volume is limited to 20 MB. Therefore, a database volume less than this size cannot be created.

The change of the default value of some system parameters of the versions before 2008 R4.0(CUBRIDSUS-4095)

Starting from 2008 R4.0, the default values of some system parameters have been changed.

Now, the default value of max_clients, which specifies the number of concurrent connections allowed by a DB server, and the default value of index_unfill_factor that specifies the ratio of reserved space for future updates while creating an index page, have been changed. Furthermore, the default values of the system parameters in bytes now use more memory when they exceed the default values of the previous system parameters per page.

Previous System Parameter Added System Parameter Previous Default Value Changed Default Value (unit: byte)
max_clients None 50 100
index_unfill_factor None 0.2 0.05
data_buffer_pages data_buffer_size 100M(page size=4K) 512M
log_buffer_pages log_buffer_size 200K(page size=4K) 4M
sort_buffer_pages sort_buffer_size 64K(page size=4K) 2M
index_scan_oid_buffer_pages index_scan_oid_buffer_size 16K(page size=4K) 64K

In addition, when a database is created using cubrid createdb, the minimum value of the data page size and the log page size has been changed from 1K to 4K.

Changed so that database services, utilities, and applications cannot be executed when the system parameter is incorrectly configured(CUBRIDSUS-5375)

It has been changed so that now the related database services, utilities, and applications are not executed when configuring system parameters that are not defined in cubrid.conf or cubrid_ha.conf, when the value of system parameters exceed the threshold, or when the system parameters per page and the system parameters in bytes are used simultaneously.

Database fails to start if the data_buffer_size is configured with a value that exceeds 2G in CUBRID 32-bit version(CUBRIDSUS-5349)

In the CUBRID 32-bit version, if the value of data_buffer_size exceeds 2G, the running database fails. Note that the configuration value cannot exceed 2G in the 32-bit version because of the OS limit.

Recommendations for controlling services with the CUBRID Utility in Windows Vista and higher(CUBRIDSUS-4186)

To control services using cubrid utility from Windows Vista and higher, it is recommended to start the command prompt window with administrative privileges.

If you don't start the command prompt window with administrative privileges and use the cubrid utility, you can still execute it with administrative privileges through the User Account Control (UAC) dialog box, but you will not be able to verify the resulting messages.

The procedures for starting the command prompt window as an administrator in Windows Vista and higher are as follows:

  • Right-click [Start > All Programs > Accessories > Command Prompt].
  • When [Execute as an administrator (A)] is selected, a dialog box to verify the privilege escalation is activated. Click “YES" to start with administrative privileges.

GLO class which is used in 2008 r3.0 or before is not supported any longer(CUBRIDSUS-3826)

CUBRID 2008 R3.0 and earlier versions processed Large Objects with the Generalized Large Object glo class, but the glo class has been removed from CUBRID 2008 R3.1 and later versions. Instead, they support BLOB and CLOB (LOB from this point forward) data types. (See BLOB/CLOB Data Types for more information about LOB data types).

glo class users are recommended to carry out tasks as follows:

  • After saving GLO data as a file, modify to not use GLO in any application and DB schema.
  • Implement DB migration by using the unloaddb and loaddb utilities.
  • Perform tasks to load files into LOB data according to the modified application.
  • Verify the application that you modified operates normally.

For reference, if the cubrid loaddb utility loads a table that inherits the GLO class or has the GLO class type, it stops the data from loading by displaying an error message, "Error occurred during schema loading."

With the discontinued support of GLO class, the deleted functions for each interface are as follows:

Interface Deleted Functions
CCI

cci_glo_append_data

cci_glo_compress_data

cci_glo_data_size

cci_glo_delete_data

cci_glo_destroy_data

cci_glo_insert_data

cci_glo_load

cci_glo_new

cci_glo_read_data

cci_glo_save

cci_glo_truncate_data

cci_glo_write_data

JDBC

CUBRIDConnection.getNewGLO

CUBRIDOID.loadGLO

CUBRIDOID.saveGLO

PHP

cubrid_new_glo

cubrid_save_to_glo

cubrid_load_from_glo

cubrid_send_glo

Port configuration is required if the protocol between the master and server processes is changed, or if two versions are running at the same time(CUBRIDSUS-3564)

Because the communication protocol between a master process (cub_master) and a server process (cub_server) has been changed, the master process of CUBRID 2008 R3.0 or later cannot communicate with the server process of a lower version, and the master process of a lower version cannot communicate with a server process of 2008 R3.0 version or later. Therefore, if you run two versions of CUBRID at the same time by adding a new version in an environment where a lower version has already been installed, you should modify the cubrid_port_id system parameter of cubrid.conf so that different ports are used by the different versions.

Specifying a question mark when entering connection information as a URL string in JDBC(CUBRIDSUS-3217)

When entering connection information as a URL string in JDBC, property information was applied even if you did not enter a question mark (?) in the earlier version. However, you must specify a question mark depending on syntax in this CUBRID 2008 R3.0 version. If not, an error is displayed. In addition, you must specify colon (:) even if there is no username or password in the connection information.

URL=jdbc:CUBRID:127.0.0.1:31000:db1:::altHosts=127.0.0.2:31000,127.0.0.3:31000 - Error
URL=jdbc:CUBRID:127.0.0.1:31000:db1:::?altHosts=127.0.0.2:31000,127.0.0.3:31000 - Normal

Not allowed to include @ in a database name(CUBRIDSUS-2828)

If @ is included in a database name, it can be interpreted that a host name has been specified. To prevent this, a revision has been made so that @ cannot be included in a database name when running cubrid createdb, cubrid renamedb and cubrid copydb utilities.