One might need to insert a large amount of data when first populating a database. This section contains some suggestions on how to make this process as efficient as possible. 14.4.1. Disable Autocommit When using multiple INSERTs, turn off autocommit and just do one commit at the end. (In plain SQL, this means issuing BEGIN at the start and COMMIT at the end. Some client libraries might do this behind your back, in which case you need to make sure the library does it when you want it done.) If

NameCHECKPOINT -- force a transaction log checkpoint Synopsis CHECKPOINT Description A checkpoint is a point in the transaction log sequence at which all data files have been updated to reflect the information in the log. All data files will be flushed to disk. Refer to Section 30.4 for more details about what happens during a checkpoint. The CHECKPOINT command forces an immediate checkpoint when the command is issued, without waiting for a regular checkpoint scheduled by the system (

The passwordcheck module checks users' passwords whenever they are set with CREATE ROLE or ALTER ROLE. If a password is considered too weak, it will be rejected and the command will terminate with an error. To enable this module, add '$libdir/passwordcheck' to shared_preload_libraries in postgresql.conf, then restart the server. You can adapt this module to your needs by changing the source code. For example, you can use CrackLib to check passwords — this only requires uncommenting two lines in

The view pg_rules provides access to useful information about query rewrite rules. Table 50-74. pg_rules Columns Name Type References Description schemaname name pg_namespace.nspname Name of schema containing table tablename name pg_class.relname Name of table the rule is for rulename name pg_rewrite.rulename Name of rule definition text Rule definition (a reconstructed creation command) The pg_rules view excludes the ON SELECT rules of views and materialized views; those can be seen in pg

Namepostmaster -- PostgreSQL database server Synopsis postmaster [option...] Description postmaster is a deprecated alias of postgres. See Also postgres Prev Next postgres Up Internals

NameRESET -- restore the value of a run-time parameter to the default value Synopsis RESET configuration_parameter RESET ALL Description RESET restores run-time parameters to their default values. RESET is an alternative spelling for SET configuration_parameter TO DEFAULT Refer to SET for details. The default value is defined as the value that the parameter would have had, if no SET had ever been issued for it in the current session. The actual source of this value might be a compil

NameSET SESSION AUTHORIZATION -- set the session user identifier and the current user identifier of the current session Synopsis SET [ SESSION | LOCAL ] SESSION AUTHORIZATION user_name SET [ SESSION | LOCAL ] SESSION AUTHORIZATION DEFAULT RESET SESSION AUTHORIZATION Description This command sets the session user identifier and the current user identifier of the current SQL session to be user_name. The user name can be written as either an identifier or a string literal. Using this com

The view pg_group exists for backwards compatibility: it emulates a catalog that existed in PostgreSQL before version 8.1. It shows the names and members of all roles that are marked as not rolcanlogin, which is an approximation to the set of roles that are being used as groups. Table 50-64. pg_group Columns Name Type References Description groname name pg_authid.rolname Name of the group grosysid oid pg_authid.oid ID of this group grolist oid[] pg_authid.oid An array containing the IDs of th

The pg_prewarm module provides a convenient way to load relation data into either the operating system buffer cache or the PostgreSQL buffer cache. F.27.1. Functions pg_prewarm(regclass, mode text default 'buffer', fork text default 'main', first_block int8 default null, last_block int8 default null) RETURNS int8 The first argument is the relation to be prewarmed. The second argument is the prewarming method to be used, as further discussed below; the third is the relat

Functions and triggers allow users to insert code into the backend server that other users might execute unintentionally. Hence, both mechanisms permit users to "Trojan horse" others with relative ease. The only real protection is tight control over who can define functions. Functions run inside the backend server process with the operating system permissions of the database server daemon. If the programming language used for the function allows unchecked memory accesses, it is possible to chan