Logger

In the philosophy of MonetDB, transaction management overhead should only be paid when necessary. Transaction management is for this purpose implemented as a separate module and applications are required obey the transaction policy, e.g. obtaining/releasing locks.

This module is designed to support efficient logging of the SQL database. Once loaded, the SQL compiler will insert the proper calls at transaction commit to include the changes in the log file.

The logger uses a directory to store its log files. One master log file stores information about the version of the logger and the transaction log files. This file is a simple ascii file with the following format: 6DIGIT-VERSION\n[log file number \n]*]* The transaction log files have a binary format, which stores fixed size logformat headers (flag,nr,bid), where the flag is the type of update logged. The 'nr' field indicates how many changes there were (in case of inserts/deletes). The bid stores the bid identifier.

The key decision to be made by the user is the location of the log file. Ideally, it should be stored in fail-safe environment, or at least the log and databases should be on separate disk columns.

This file system may reside on the same hardware as the database server and therefore the writes are done to the same disk, but could also reside on another system and then the changes are flushed through the network. The logger works under the assumption that it is called to safeguard updates on the database when it has an exclusive lock on the latest version. This lock should be guaranteed by the calling transaction manager first.

Finding the updates applied to a BAT is relatively easy, because each BAT contains a delta structure. On commit these changes are written to the log file and the delta management is reset. Since each commit is written to the same log file, the beginning and end are marked by a log identifier.

A server restart should only (re)process blocks which are completely written to disk. A log replay therefore ends in a commit or abort on the changed bats. Once all logs have been read, the changes to the bats are made persistent, i.e. a bbp sub-commit is done.

MODULE logging;

PATTERN logging.compinfo() (X_0:bat[:int], X_1:bat[:str], X_2:bat[:str]);
COMMENT "Returns in the form of a SQL result-set all the components along with their ID\nand the their current logging level being set";

UNSAFE COMMAND logging.flush():void;
COMMENT "Flush the buffer";

UNSAFE COMMAND logging.resetadapter():void;
COMMENT "Resets the adapter back to the default";

UNSAFE COMMAND logging.resetcomplevel(X_0:str):void;
COMMENT "Resets the log level for a specific component back to the default";

UNSAFE COMMAND logging.resetflushlevel():void;
COMMENT "Resets the flush level back to the default";

UNSAFE COMMAND logging.resetlayerlevel(X_0:str):void;
COMMENT "Resets the log level for a specific layer back to the default";

UNSAFE COMMAND logging.setadapter(X_0:str):void;
COMMENT "Sets the adapter";

UNSAFE COMMAND logging.setcomplevel(X_0:str, X_1:str):void;
COMMENT "Sets the log level for a specific component";

UNSAFE COMMAND logging.setflushlevel(X_0:str):void;
COMMENT "Sets the flush level";

UNSAFE COMMAND logging.setlayerlevel(X_0:str, X_1:str):void;
COMMENT "Sets the log level for a specific layer";