The file_fdw module provides the foreign-data wrapper file_fdw, which can be used to access data files in the server's file system. Data files must be in a format that can be read by COPY FROM; see COPY for details. Access to such data files is currently read-only. A foreign table created using this wrapper can have the following options: filename Specifies the file to be read. Required. Must be an absolute path name. format Specifies the file's format, the same as COPY's FORMAT option. he

An alternative backup strategy is to directly copy the files that PostgreSQL uses to store the data in the database; Section 18.2 explains where these files are located. You can use whatever method you prefer for doing file system backups; for example: tar -cf backup.tar /usr/local/pgsql/data There are two restrictions, however, which make this method impractical, or at least inferior to the pg_dump method: The database server must be shut down in order to get a usable backup. Half-way measu

If the primary server fails then the standby server should begin failover procedures. If the standby server fails then no failover need take place. If the standby server can be restarted, even some time later, then the recovery process can also be restarted immediately, taking advantage of restartable recovery. If the standby server cannot be restarted, then a full new standby server instance should be created. If the primary server fails and the standby server becomes the new primary, and then

PostgreSQL provides various lock modes to control concurrent access to data in tables. These modes can be used for application-controlled locking in situations where MVCC does not give the desired behavior. Also, most PostgreSQL commands automatically acquire locks of appropriate modes to ensure that referenced tables are not dropped or modified in incompatible ways while the command executes. (For example, TRUNCATE cannot safely be executed concurrently with other operations on the same table,

NameFETCH -- retrieve rows from a query using a cursor Synopsis FETCH [ direction [ FROM | IN ] ] cursor_name where direction can be empty or one of: NEXT PRIOR FIRST LAST ABSOLUTE count RELATIVE count count ALL FORWARD FORWARD count FORWARD ALL BACKWARD BACKWARD count BACKWARD ALL Description FETCH retrieves rows using a previously-created cursor. A cursor has an associated position, which is used by FETCH. The cursor position

NameEXPLAIN -- show the execution plan of a statement Synopsis EXPLAIN [ ( option [, ...] ) ] statement EXPLAIN [ ANALYZE ] [ VERBOSE ] statement where option can be one of: ANALYZE [ boolean ] VERBOSE [ boolean ] COSTS [ boolean ] BUFFERS [ boolean ] TIMING [ boolean ] FORMAT { TEXT | XML | JSON | YAML } Description This command displays the execution plan that the PostgreSQL planner generates for the supplied statement. The execution plan shows how the tabl

NameEXECUTE -- execute a prepared statement Synopsis EXECUTE name [ ( parameter [, ...] ) ] Description EXECUTE is used to execute a previously prepared statement. Since prepared statements only exist for the duration of a session, the prepared statement must have been created by a PREPARE statement executed earlier in the current session. If the PREPARE statement that created the statement specified some parameters, a compatible set of parameters must be passed to the EXECUTE stateme

This style guide is offered in the hope of maintaining a consistent, user-friendly style throughout all the messages generated by PostgreSQL. 52.3.1. What Goes Where The primary message should be short, factual, and avoid reference to implementation details such as specific function names. "Short" means "should fit on one line under normal conditions". Use a detail message if needed to keep the primary message short, or if you feel a need to mention implementation details such as the particula

PostgreSQL provides these helper functions to retrieve information from event triggers. For more information about event triggers, see Chapter 38. 9.28.1. Capturing Changes at Command End pg_event_trigger_ddl_commands returns a list of DDL commands executed by each user action, when invoked in a function attached to a ddl_command_end event trigger. If called in any other context, an error is raised. pg_event_trigger_ddl_commands returns one row for each base command executed; some commands tha

Although indexes in PostgreSQL do not need maintenance or tuning, it is still important to check which indexes are actually used by the real-life query workload. Examining index usage for an individual query is done with the EXPLAIN command; its application for this purpose is illustrated in Section 14.1. It is also possible to gather overall statistics about index usage in a running server, as described in Section 28.2. It is difficult to formulate a general procedure for determining which ind