Controls which message levels are sent to the client. Valid values are DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING, and ERROR. Each level includes all the levels that follow it. The later the level, the fewer messages are sent. The default is NOTICE. Note that LOG has a different rank here than in log_min_messages.

INFO level messages are always sent to the client.

This variable specifies the order in which schemas are searched when an object (table, data type, function, etc.) is referenced by a simple name with no schema specified. When there are objects of identical names in different schemas, the one found first in the search path is used. An object that is not in any of the schemas in the search path can only be referenced by specifying its containing schema with a qualified (dotted) name.

The value for search_path must be a comma-separated list of schema names. Any name that is not an existing schema, or is a schema for which the user does not have USAGE permission, is silently ignored.

If one of the list items is the special name $user, then the schema having the name returned by CURRENT_USER is substituted, if there is such a schema and the user has USAGE permission for it. (If not, $user is ignored.)

If one of the list items is the special name $lt_syntax_compatible_type and lightdb_dblevel_syntax_compatible_type is not off, then the schema having the name returned by lt_syntax_compatible_type is substituted,if there is such a schema and the user has USAGE permission for it. (If lightdb_dblevel_syntax_compatible_type is off, $lt_syntax_compatible_type is ignored.)

The system catalog schema, pg_catalog, is always searched, whether it is mentioned in the path or not. If it is mentioned in the path then it will be searched in the specified order. If pg_catalog is not in the path then it will be searched before searching any of the path items.

Likewise, the current session's temporary-table schema, pg_temp_nnn, is always searched if it exists. It can be explicitly listed in the path by using the alias pg_temp. If it is not listed in the path then it is searched first (even before pg_catalog). However, the temporary schema is only searched for relation (table, view, sequence, etc) and data type names. It is never searched for function or operator names.

When objects are created without specifying a particular target schema, they will be placed in the first valid schema named in search_path. An error is reported if the search path is empty.

The default value for this parameter is "$user", public,$lt_syntax_compatible_type, lt_catalog. This setting supports shared use of a database (where no users have private schemas, and all share use of public), private per-user schemas, and combinations of these. Other effects can be obtained by altering the default search path setting, either globally or per-user.

For more information on schema handling, see Section 6.9. In particular, the default configuration is suitable only when the database has a single user or a few mutually-trusting users.

The current effective value of the search path can be examined via the SQL function current_schemas (see Section 10.25). This is not quite the same as examining the value of search_path, since current_schemas shows how the items appearing in search_path were resolved.

mysql and oracle are special schemas, which can only be include in the specified lightdb_dblevel_syntax_compatible_type.

This variable controls whether to raise an error in lieu of applying a row security policy. When set to on, policies apply normally. When set to off, queries fail which would otherwise apply at least one policy. The default is on. Change to off where limited row visibility could cause incorrect results; for example, lt_dump makes that change by default. This variable has no effect on roles which bypass every row security policy, to wit, superusers and roles with the BYPASSRLS attribute.

For more information on row security policies, see CREATE POLICY.

This parameter specifies the default table access method to use when creating tables if the CREATE command does not explicitly specify an access method, or when SELECT ... INTO is used, which does not allow specifying a table access method. The default is heap.

This variable specifies the default tablespace in which to create objects (tables and indexes) when a CREATE command does not explicitly specify a tablespace.

The value is either the name of a tablespace, or an empty string to specify using the default tablespace of the current database. If the value does not match the name of any existing tablespace, LightDB will automatically use the default tablespace of the current database. If a nondefault tablespace is specified, the user must have CREATE privilege for it, or creation attempts will fail.

This variable is not used for temporary tables; for them, temp_tablespaces is consulted instead.

This variable is also not used when creating databases. By default, a new database inherits its tablespace setting from the template database it is copied from.

If this parameter is set to a value other than the empty string when a partitioned table is created, the partitioned table's tablespace will be set to that value, which will be used as the default tablespace for partitions created in the future, even if default_tablespace has changed since then.

For more information on tablespaces, see Section 21.6.

This variable specifies tablespaces in which to create temporary objects (temp tables and indexes on temp tables) when a CREATE command does not explicitly specify a tablespace. Temporary files for purposes such as sorting large data sets are also created in these tablespaces.

The value is a list of names of tablespaces. When there is more than one name in the list, LightDB chooses a random member of the list each time a temporary object is to be created; except that within a transaction, successively created temporary objects are placed in successive tablespaces from the list. If the selected element of the list is an empty string, LightDB will automatically use the default tablespace of the current database instead.

When temp_tablespaces is set interactively, specifying a nonexistent tablespace is an error, as is specifying a tablespace for which the user does not have CREATE privilege. However, when using a previously set value, nonexistent tablespaces are ignored, as are tablespaces for which the user lacks CREATE privilege. In particular, this rule applies when using a value set in lightdb.conf.

The default value is an empty string, which results in all temporary objects being created in the default tablespace of the current database.

See also default_tablespace.

This parameter is normally on. When set to off, it disables validation of the function body string during CREATE FUNCTION. Disabling validation avoids side effects of the validation process and avoids false positives due to problems such as forward references. Set this parameter to off before loading functions on behalf of other users; lt_dump does so automatically.

This parameter is normally off. When set to on, it enables validation existence of tables and their columns in the routine body string during CREATE FUNCTION and CREATE PROCEDURE.

Each SQL transaction has an isolation level, which can be either “read uncommitted”, “read committed”, “repeatable read”, or “serializable”. This parameter controls the default isolation level of each new transaction. The default is “read committed”.

Consult Chapter 14 and SET TRANSACTION for more information.

A read-only SQL transaction cannot alter non-temporary tables. This parameter controls the default read-only status of each new transaction. The default is off (read/write).

Consult SET TRANSACTION for more information.

When running at the serializable isolation level, a deferrable read-only SQL transaction may be delayed before it is allowed to proceed. However, once it begins executing it does not incur any of the overhead required to ensure serializability; so serialization code will have no reason to force it to abort because of concurrent updates, making this option suitable for long-running read-only transactions.

This parameter controls the default deferrable status of each new transaction. It currently has no effect on read-write transactions or those operating at isolation levels lower than serializable. The default is off.

Consult SET TRANSACTION for more information.

This parameter reflects the current transaction's isolation level. At the beginning of each transaction, it is set to the current value of default_transaction_isolation. Any subsequent attempt to change it is equivalent to a SET TRANSACTION command.

This parameter reflects the current transaction's read-only status. At the beginning of each transaction, it is set to the current value of default_transaction_read_only. Any subsequent attempt to change it is equivalent to a SET TRANSACTION command.

This parameter reflects the current transaction's deferrability status. At the beginning of each transaction, it is set to the current value of default_transaction_deferrable. Any subsequent attempt to change it is equivalent to a SET TRANSACTION command.

Controls firing of replication-related triggers and rules for the current session. Setting this variable requires superuser privilege and results in discarding any previously cached query plans. Possible values are origin (the default), replica and local.

The intended use of this setting is that logical replication systems set it to replica when they are applying replicated changes. The effect of that will be that triggers and rules (that have not been altered from their default configuration) will not fire on the replica. See the ALTER TABLE clauses ENABLE TRIGGER and ENABLE RULE for more information.

LightDB treats the settings origin and local the same internally. Third-party replication systems may use these two values for their internal purposes, for example using local to designate a session whose changes should not be replicated.

Since foreign keys are implemented as triggers, setting this parameter to replica also disables all foreign key checks, which can leave data in an inconsistent state if improperly used.

Abort any statement that takes more than the specified amount of time. If log_min_error_statement is set to ERROR or lower, the statement that timed out will also be logged. If this value is specified without units, it is taken as milliseconds. A value of zero (the default) disables the timeout.

The timeout is measured from the time a command arrives at the server until it is completed by the server. If multiple SQL statements appear in a single simple-Query message, the timeout is applied to each statement separately. (LightDB versions before 13 usually treated the timeout as applying to the whole query string.) In extended query protocol, the timeout starts running when any query-related message (Parse, Bind, Execute, Describe) arrives, and it is canceled by completion of an Execute or Sync message.

Setting statement_timeout in lightdb.conf is not recommended because it would affect all sessions.

Abort any statement that waits longer than the specified amount of time while attempting to acquire a lock on a table, index, row, or other database object. The time limit applies separately to each lock acquisition attempt. The limit applies both to explicit locking requests (such as LOCK TABLE, or SELECT FOR UPDATE without NOWAIT) and to implicitly-acquired locks. If this value is specified without units, it is taken as milliseconds. A value of zero (the default) disables the timeout.

Unlike statement_timeout, this timeout can only occur while waiting for locks. Note that if statement_timeout is nonzero, it is rather pointless to set lock_timeout to the same or larger value, since the statement timeout would always trigger first. If log_min_error_statement is set to ERROR or lower, the statement that timed out will be logged.

Setting lock_timeout in lightdb.conf is not recommended because it would affect all sessions.

Terminate any session that has been idle (that is, waiting for a client query) within an open transaction for longer than the specified amount of time. If this value is specified without units, it is taken as milliseconds. A value of zero (the default) disables the timeout.

This option can be used to ensure that idle sessions do not hold locks for an unreasonable amount of time. Even when no significant locks are held, an open transaction prevents vacuuming away recently-dead tuples that may be visible only to this transaction; so remaining idle for a long time can contribute to table bloat. See Section 23.1 for more details.

Terminate any session that has been idle (that is, waiting for a client query), but not within an open transaction, for longer than the specified amount of time. If this value is specified without units, it is taken as milliseconds. A value of zero (the default) disables the timeout.

Unlike the case with an open transaction, an idle session without a transaction imposes no large costs on the server, so there is less need to enable this timeout than idle_in_transaction_session_timeout.

Be wary of enforcing this timeout on connections made through connection-pooling software or other middleware, as such a layer may not react well to unexpected connection closure. It may be helpful to enable this timeout only for interactive sessions, perhaps by applying it only to particular users.

VACUUM performs an aggressive scan if the table's pg_class.relfrozenxid field has reached the age specified by this setting. An aggressive scan differs from a regular VACUUM in that it visits every page that might contain unfrozen XIDs or MXIDs, not just those that might contain dead tuples. The default is 150 million transactions. Although users can set this value anywhere from zero to two billion, VACUUM will silently limit the effective value to 95% of autovacuum_freeze_max_age, so that a periodic manual VACUUM has a chance to run before an anti-wraparound autovacuum is launched for the table. For more information see Section 23.1.5.

Specifies the cutoff age (in transactions) that VACUUM should use to decide whether to freeze row versions while scanning a table. The default is 50 million transactions. Although users can set this value anywhere from zero to one billion, VACUUM will silently limit the effective value to half the value of autovacuum_freeze_max_age, so that there is not an unreasonably short time between forced autovacuums. For more information see Section 23.1.5.

VACUUM performs an aggressive scan if the table's pg_class.relminmxid field has reached the age specified by this setting. An aggressive scan differs from a regular VACUUM in that it visits every page that might contain unfrozen XIDs or MXIDs, not just those that might contain dead tuples. The default is 150 million multixacts. Although users can set this value anywhere from zero to two billion, VACUUM will silently limit the effective value to 95% of autovacuum_multixact_freeze_max_age, so that a periodic manual VACUUM has a chance to run before an anti-wraparound is launched for the table. For more information see Section 23.1.5.1.

Specifies the cutoff age (in multixacts) that VACUUM should use to decide whether to replace multixact IDs with a newer transaction ID or multixact ID while scanning a table. The default is 5 million multixacts. Although users can set this value anywhere from zero to one billion, VACUUM will silently limit the effective value to half the value of autovacuum_multixact_freeze_max_age, so that there is not an unreasonably short time between forced autovacuums. For more information see Section 23.1.5.1.

Sets the output format for values of type bytea. Valid values are hex (the default) and escape (the traditional LightDB format). See Section 9.3 for more information. The bytea type always accepts both formats on input, regardless of this setting.

Sets how binary values are to be encoded in XML. This applies for example when bytea values are converted to XML by the functions xmlelement or xmlforest. Possible values are base64 and hex, which are both defined in the XML Schema standard. The default is base64. For further information about XML-related functions, see Section 10.14.

The actual choice here is mostly a matter of taste, constrained only by possible restrictions in client applications. Both methods support all possible values, although the hex encoding will be somewhat larger than the base64 encoding.

Sets whether DOCUMENT or CONTENT is implicit when converting between XML and character string values. See Section 9.11 for a description of this. Valid values are DOCUMENT and CONTENT. The default is CONTENT.

According to the SQL standard, the command to set this option is

SET XML OPTION { DOCUMENT | CONTENT };

This syntax is also available in LightDB.

Sets the maximum size of a GIN index's pending list, which is used when fastupdate is enabled. If the list grows larger than this maximum size, it is cleaned up by moving the entries in it to the index's main GIN data structure in bulk. If this value is specified without units, it is taken as kilobytes. The default is four megabytes (4MB). This setting can be overridden for individual GIN indexes by changing index storage parameters. See Section 60.4.1 and Section 60.5 for more information.

This variable specifies relation kind to which access is restricted. It contains a comma-separated list of relation kind. Currently, the supported relation kinds are view and foreign-table.

Valid values are Oracle, MySQL, off. The default value is off. Set the default value of the create database command. For example,when the value is oracle,"create database test" is equivalent to "create database test with lightdb_syntax_compatible_type oracle".

report the syntax compatible type for current database. It is determined by the value of lightdb_syntax_compatible_type when database is created.

When the value is set to Oracle, the following features are different:

When the value is set to MySQL, the following features are different:

In MySQL compatibility mode, whether to enable the all-lowercase feature of table names. The value is true or false, the default value is true. true: enable false: disable

It is determined by the value of lightdb_ascii_zero_store_value when the database is created, this value only make means when the database compatible type is set to Oracle or Mysql.

Lightdb 23.3 introduced a new database level GUC parameter lightdb_ascii_zero_store_value, the value must be within the valid range of 0 to 32, inclusive of both 0 and 32, and the value can not be changed once the database be created.

If the database compatible type is set to Oracle or Mysql, and lightdb_ascii_zero_store_value is set to non-zero ASCII value, ASCII value E'\0' and CHR(0) would result in the ASCII value equal to lightdb_ascii_zero_store_value, if we do a query by JDBC and send the bind parameter in text type, ASCII value '\0' would be replaced into ASCII value lightdb_ascii_zero_store_value on server side, as for Libpq in this bind parameter case, the ASCII value replacement happens on Libpq side. Please also note that, if ASCII value '\0' is replaced by ASCII value lightdb_ascii_zero_store_value, the later behaviors (after ASCII value '\0' be replaced) of ASCII value '\0' character in the system would be the same as ASCII value of lightdb_ascii_zero_store_value , such as order compare, function call of concat, length, ascii, and other function that accept character as input parameter.

In Oracle compatibility mode, convert Chinese commas and Chinese spaces in SQL statements to English commas and spaces. The value is true or false, the default value is true. true: enable false: disable

This GUC parameter is introduced in Lightdb 23.4. It is used to decide how to process the conflict of TEMPLATE and LIGHTDB_SYNTAX_COMPATIBLE_TYPE options in CREATE DATABASE. When the two options are conflict, an error will be reported when its value is false, otherwise the TEMPLATE option will be ignored. The value is true or false, the default value is false.

Sets the display format for date and time values, as well as the rules for interpreting ambiguous date input values. For historical reasons, this variable contains two independent components: the output format specification (ISO, Postgres, SQL, or German) and the input/output specification for year/month/day ordering (DMY, MDY, or YMD). These can be set separately or together. The keywords Euro and European are synonyms for DMY; the keywords US, NonEuro, and NonEuropean are synonyms for MDY. See Section 9.4 for more information. The built-in default is ISO, MDY, but lt_initdb will initialize the configuration file with a setting that corresponds to the behavior of the chosen lc_time locale.

Sets the display format for interval values. The value sql_standard will produce output matching SQL standard interval literals. The value postgres (which is the default) will produce output matching postgres releases prior to 8.4 when the DateStyle parameter was set to ISO. The value postgres_verbose will produce output matching postgres releases prior to 8.4 when the DateStyle parameter was set to non-ISO output. The value iso_8601 will produce output matching the time interval “format with designators” defined in section 4.4.3.2 of ISO 8601.

The IntervalStyle parameter also affects the interpretation of ambiguous interval input. See Section 9.4.4 for more information.

Sets the time zone for displaying and interpreting time stamps. The built-in default is GMT, but that is typically overridden in lightdb.conf; lt_initdb will install a setting there corresponding to its system environment. See Section 9.4.3 for more information.

Sets the collection of time zone abbreviations that will be accepted by the server for datetime input. The default is 'Default', which is a collection that works in most of the world; there are also 'Australia' and 'India', and other collections can be defined for a particular installation. See Section B.4 for more information.

This parameter adjusts the number of digits used for textual output of floating-point values, including float4, float8, and geometric data types.

If the value is 1 (the default) or above, float values are output in shortest-precise format; see Section 9.1.3. The actual number of digits generated depends only on the value being output, not on the value of this parameter. At most 17 digits are required for float8 values, and 9 for float4 values. This format is both fast and precise, preserving the original binary float value exactly when correctly read. For historical compatibility, values up to 3 are permitted.

If the value is zero or negative, then the output is rounded to a given decimal precision. The precision used is the standard number of digits for the type (FLT_DIG or DBL_DIG as appropriate) reduced according to the value of this parameter. (For example, specifying -1 will cause float4 values to be output rounded to 5 significant digits, and float8 values rounded to 14 digits.) This format is slower and does not preserve all the bits of the binary float value, but may be more human-readable.

Sets the client-side encoding (character set). The default is to use the database encoding. The character sets supported by the LightDB server are described in Section 22.3.1.

Sets the language in which messages are displayed. Acceptable values are system-dependent; see Section 22.1 for more information. If this variable is set to the empty string (which is the default) then the value is inherited from the execution environment of the server in a system-dependent way.

On some systems, this locale category does not exist. Setting this variable will still work, but there will be no effect. Also, there is a chance that no translated messages for the desired language exist. In that case you will continue to see the English messages.

Only superusers can change this setting, because it affects the messages sent to the server log as well as to the client, and an improper value might obscure the readability of the server logs.

Sets the locale to use for formatting monetary amounts, for example with the to_char family of functions. Acceptable values are system-dependent; see Section 22.1 for more information. If this variable is set to the empty string (which is the default) then the value is inherited from the execution environment of the server in a system-dependent way.

Sets the locale to use for formatting numbers, for example with the to_char family of functions. Acceptable values are system-dependent; see Section 22.1 for more information. If this variable is set to the empty string (which is the default) then the value is inherited from the execution environment of the server in a system-dependent way.

Sets the locale to use for formatting dates and times, for example with the to_char family of functions. Acceptable values are system-dependent; see Section 22.1 for more information. If this variable is set to the empty string (which is the default) then the value is inherited from the execution environment of the server in a system-dependent way.

Selects the text search configuration that is used by those variants of the text search functions that do not have an explicit argument specifying the configuration. See Chapter 13 for further information. The built-in default is pg_catalog.simple, but lt_initdb will initialize the configuration file with a setting that corresponds to the chosen lc_ctype locale, if a configuration matching that locale can be identified.

LightDB full text search has many built-in stop words. Words connected by stop words will be split into multiple independent words by to_tsvector function, for example, "2022-04-10" will be split into "2022", "04" and "10". lightdb_tsearch_non_stopwords is used to customize non-stop words, which is just the opposite of stop words, that is, non-stop words are considered to be an integral part of a word and thus will not be split into multiple independent words by to_tsvector function any more. Still the above example, if you set '-' as non-stop words, you will only get a result of "2022-04-10". The following characters can be used as non stop words in LightDB. Choose freely from the following characters to improve the accuracy and ease of use of full text serach by this. Supported nonstopwords list:

        ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~
        

See Chapter 13 for further information.

The built-in default vaule is '', you can update lightdb_tsearch_non_stopwords values in lightdb.conf. but if you update lightdb_tsearch_non_stopwords in lightdb.conf, you must restart the server to take effect. You can also update lightdb_tsearch_non_stopwords by set lightdb_tsearch_non_stopwords during session without restart server. Selects any combination of characters from the nonstopwords list , For example:

        lightdb@postgres=# set lightdb_tsearch_non_stopwords = '@-=:_';
        SET
        lightdb@postgres=# select to_tsvector('this is from lt_hs_tab table logged at 2020-12-21 00:22:32, username=zjh&pwd=balabala www.light-pg');
                                                          to_tsvector                                                   
        ----------------------------------------------------------------------------------------------------------------
        '00:22:32':9 '2020-12-21':8 'log':6 'lt_hs_tab':4 'pwd=balabala':11 'tabl':5 'username=zjh':10 'www.light-pg':12
        (1 row)

        lightdb@postgres=# set lightdb_tsearch_non_stopwords = '';
        SET
        lightdb@postgres=# select to_tsvector('this is from lt_hs_tab table logged at 2020-12-21 00:22:32, username=zjh&pwd=balabala www.light-pg');
                                                                              to_tsvector                                                                       
        ---------------------------------------------------------------------------------------------------------------------------------------------------------
        '-12':11 '-21':12 '00':13 '2020':10 '22':14 '32':15 'balabala':19 'hs':5 'log':8 'lt':4 'pwd':18 'tab':6 'tabl':7 'usernam':16 'www.light-pg':20 'zjh':17
        (1 row)

        

If the configuration lightdb_tsearch_non_stopwords parameter is invalid, an error will be reported. For example:

        lightdb@postgres=# set lightdb_tsearch_non_stopwords = '1@';
        ERROR:  invalid value for parameter "lightdb_tsearch_non_stopwords": "1@"
        DETAIL:  lightdb_tsearch_non_stopwords not support '1@' as non stopword.
        

lightdb_tsearch_word_superpose is used to overlay the effect of using stop words and non-stop words. For example, if you set lightdb_tsearch_word_superpose to on and set lightdb_tsearch_non_stopwords to '-', you will get the results including "2022", "04", "10" and "2022-04-10" at the same time when using to_tsvector("2022-04-10"). See Chapter 13 for further information.

The built-in default vaule is off, you can update lightdb_tsearch_word_superpose value in lightdb.conf, but if you update lightdb_tsearch_word_superpose in lightdb.conf, you must restart the server to take effect. You can also update lightdb_tsearch_word_superpose by set lightdb_tsearch_word_superpose during session without restart server. Chinese text is not supported. For example:

        lightdb@postgres=# set lightdb_tsearch_word_superpose = off;
        SET
        lightdb@postgres=# select to_tsvector('this is from lt_hs_tab table logged at 2020-12-21 00:22:32, username=zjh&pwd=balabala www.light-pg');
                                                                              to_tsvector                                                                       
        ---------------------------------------------------------------------------------------------------------------------------------------------------------
        '-12':11 '-21':12 '00':13 '2020':10 '22':14 '32':15 'balabala':19 'hs':5 'log':8 'lt':4 'pwd':18 'tab':6 'tabl':7 'usernam':16 'www.light-pg':20 'zjh':17
        (1 row)

        lightdb@postgres=# set lightdb_tsearch_word_superpose = on;
        SET
        lightdb@postgres=# select to_tsvector('this is from lt_hs_tab table logged at 2020-12-21 00:22:32, username=zjh&pwd=balabala www.light-pg');
                                                                                                                    to_tsvector                                                                    
                                                
        --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
        -----------------------------------------
        '-12':33 '-21':34 '00':13,35 '12':11 '2020':10,32 '21':12 '22':14,36 '32':15,37 'balabala':19,41 'hs':5,21,27 'log':8,30 'lt':4,26 'net':22 'pwd':18,40 'tab':6,28 'tabl':7,29 'usernam':16
        ,38 'www':20 'www.light-pg':42 'zjh':17,39
        (1 row)

        

The key path used to store Transparent Data Encryption, which ensures that the TDE key will be read again after each restart of the data.

See Chapter 31 for further information.

When Transparent Data Encryption is not used, this parameter is null. Only when Transparent Data Encryption is configured, this parameter stores the tde key. A setting example using the SET statement is shown below.

show lightdb_encryption_key_command;
   lightdb_encryption_key_command   
------------------------------------
 /home/lightdb/stage/provide_key.sh
(1 row)
        

Only in Oracle compatible mode, lightdb can configure nls_date_format parameter sets the display output format of sysdate and type timestamp.

See Section 10.9 for further information.

You must set a sysdate format for the nls_date_format variable in advance. A setting example using the SET statement is shown below.

SET nls_date_format = 'YYYY/MM/DD HH24:MI:SS';

select sysdate;
       sysdate       
---------------------
 2022/09/15 10:03:29
(1 row)

select to_char(sysdate);
       to_char       
---------------------
 2022/09/15 10:08:46
(1 row)
        

Only in Oracle compatible mode, lightdb can configure nls_timestamp_format parameter sets the display output format of systimestamp and type timestamptz.

See Section 10.9 for further information.

You must set a systimestamp format for the nls_timestamp_format variable in advance. A setting example using the SET statement is shown below.

SET nls_timestamp_format = 'YYYY/MM/DD HH24:MI:SS.FF6TZH';

select systimestamp;
         systimestamp          
-------------------------------
 2022/09/15 10:05:56.884814+08
(1 row)
        

Only in MySQL compatibility mode, this parameter is used to control whether the SELECT DISTINCT...ORDER BY syntax of msyql is compatible with that of msyql other than ONLY_FULL_GROUP_BY. The default value of this parameter is on.

By default, lightdb will report errors for inconsistent columns in the SELECT DISTINCT...ORDER BY syntax:

select distinct a from test_distinct_order_tb1 order by d;
ERROR:  for SELECT DISTINCT, ORDER BY expressions must appear in select list
LINE 1: select distinct a from test_distinct_order_tb1 order by d;
                                                                ^
        

Only in MySQL compatibility mode and lightdb_only_full_group_by setting off, the above SQL can be executed normally:

set lightdb_only_full_group_by = off;
SET

select distinct a from test_distinct_order_tb1 order by d;
 a 
---
 3
 1
 2
(3 rows)
        

Note that this behavior is only a nonstandard syntax compatible with MySQL. It is used to ensure that the execution in LightDB will not report errors, but the results cannot be guaranteed to be completely consistent with MySQL. It is not recommended to use this feature. Please use the standard syntax format.

This variable specifies one or more shared libraries that are to be preloaded at connection start. It contains a comma-separated list of library names, where each name is interpreted as for the LOAD command. Whitespace between entries is ignored; surround a library name with double quotes if you need to include whitespace or commas in the name. The parameter value only takes effect at the start of the connection. Subsequent changes have no effect. If a specified library is not found, the connection attempt will fail.

This option can be set by any user. Because of that, the libraries that can be loaded are restricted to those appearing in the plugins subdirectory of the installation's standard library directory. (It is the database administrator's responsibility to ensure that only “safe” libraries are installed there.) Entries in local_preload_libraries can specify this directory explicitly, for example $libdir/plugins/mylib, or just specify the library name — mylib would have the same effect as $libdir/plugins/mylib.

The intent of this feature is to allow unprivileged users to load debugging or performance-measurement libraries into specific sessions without requiring an explicit LOAD command. To that end, it would be typical to set this parameter using the LTOPTIONS environment variable on the client or by using ALTER ROLE SET.

However, unless a module is specifically designed to be used in this way by non-superusers, this is usually not the right setting to use. Look at session_preload_libraries instead.

This variable specifies one or more shared libraries that are to be preloaded at connection start. It contains a comma-separated list of library names, where each name is interpreted as for the LOAD command. Whitespace between entries is ignored; surround a library name with double quotes if you need to include whitespace or commas in the name. The parameter value only takes effect at the start of the connection. Subsequent changes have no effect. If a specified library is not found, the connection attempt will fail. Only superusers can change this setting.

The intent of this feature is to allow debugging or performance-measurement libraries to be loaded into specific sessions without an explicit LOAD command being given. For example, auto_explain could be enabled for all sessions under a given user name by setting this parameter with ALTER ROLE SET. Also, this parameter can be changed without restarting the server (but changes only take effect when a new session is started), so it is easier to add new modules this way, even if they should apply to all sessions.

Unlike shared_preload_libraries, there is no large performance advantage to loading a library at session start rather than when it is first used. There is some advantage, however, when connection pooling is used.

This variable specifies one or more shared libraries to be preloaded at server start. It contains a comma-separated list of library names, where each name is interpreted as for the LOAD command. Whitespace between entries is ignored; surround a library name with double quotes if you need to include whitespace or commas in the name. This parameter can only be set at server start. If a specified library is not found, the server will fail to start.

Some libraries need to perform certain operations that can only take place at postmaster start, such as allocating shared memory, reserving light-weight locks, or starting background workers. Those libraries must be loaded at server start through this parameter. See the documentation of each library for details.

Other libraries can also be preloaded. By preloading a shared library, the library startup time is avoided when the library is first used. However, the time to start each new server process might increase slightly, even if that process never uses the library. So this parameter is recommended only for libraries that will be used in most sessions. Also, changing this parameter requires a server restart, so this is not the right setting to use for short-term debugging tasks, say. Use session_preload_libraries for that instead.

If a dynamically loadable module needs to be opened and the file name specified in the CREATE FUNCTION or LOAD command does not have a directory component (i.e., the name does not contain a slash), the system will search this path for the required file.

The value for dynamic_library_path must be a list of absolute directory paths separated by colons. If a list element starts with the special string $libdir, the compiled-in LightDB package library directory is substituted for $libdir; this is where the modules provided by the standard LightDB distribution are installed. (Use lt_config --pkglibdir to find out the name of this directory.) For example:

dynamic_library_path = '/usr/local/lib/lightdb:/home/my_project/lib:$libdir'

The default value for this parameter is '$libdir'. If the value is set to an empty string, the automatic path search is turned off.

This parameter can be changed at run time by superusers, but a setting done that way will only persist until the end of the client connection, so this method should be reserved for development purposes. The recommended way to set this parameter is in the lightdb.conf configuration file.

Soft upper limit of the size of the set returned by GIN index scans. For more information see Section 60.5.