--- /tmp/bgworker.old.sgml 2012-12-05 22:12:00.220609454 +0100 +++ /tmp/bgworker.sgml 2012-12-05 22:26:11.604712943 +0100 @@ -11,16 +11,16 @@ PostgreSQL can be extended to run user-supplied code in separate processes. Such processes are started, stopped and monitored by postgres, - which permits them have a lifetime closely linked to the server's status. + which permits them to have a lifetime closely linked to the server's status. These processes have the option to attach to PostgreSQL's - shared memory area and connect to databases internally. + shared memory area and to connect to databases internally. There are considerable robustness and security risks in using background - worker processes, because them being written in the C language - gives them unrestricted access to data. Administrators wishing to enable + worker processes because, being written in the C language, + they have unrestricted access to data. Administrators wishing to enable modules that include background worker process should exercise extreme caution. Only carefully audited modules should be permitted to run background worker processes. @@ -31,7 +31,8 @@ Only modules listed in shared_preload_libraries can run background workers. A module wishing to register a background worker needs to register it by calling - RegisterBackgroundWorker(BackgroundWorker *worker). + RegisterBackgroundWorker(BackgroundWorker *worker) + from it's _PG_Init(). The structure BackgroundWorker is defined thus: typedef struct BackgroundWorker @@ -50,12 +51,12 @@ bgw_name is a string to be used in log messages, process - lists and similar contexts. + listings and similar contexts. bgw_flags is a bitwise-or'd bitmask indicating the - capabilities that the module would like to have. Possible values are + capabilities that the module wants. Possible values are BGWORKER_SHMEM_ACCESS (requesting shared memory access) and BGWORKER_BACKEND_DATABASE_CONNECTION (requesting the ability to establish a database connection, through which it can later run @@ -68,33 +69,35 @@ BgWorkerStart_PostmasterStart (start as soon as postgres itself has finished its own initialization; processes requesting this are not eligible for database connections), - BgWorkerStart_ConsistentState (start as soon as consistent state + BgWorkerStart_ConsistentState (start as soon as a consistent state has been reached in a HOT standby, allowing processes to connect to databases and run read-only queries), and BgWorkerStart_RecoveryFinished (start as soon as the system has entered normal read-write state). Note the last two values are equivalent in a server that's not a HOT standby. - + bgw_restart_time is the interval, in seconds, that - postgres should wait before restarting the process, - in case it crashes. It can be any positive value, or BGW_NEVER_RESTART, indicating not to restart the process in case of a crash. + postgres should wait before restarting the process, in + case it crashes. It can be any positive value, + or BGW_NEVER_RESTART, indicating not to restart the + process in case of a crash. bgw_main is a pointer to the function to run once the process is started. bgw_main_arg will be - passed to it as its only argument. Note that - MyBgworkerEntry is a pointer to a copy of the - BackgroundWorker structure passed - at registration time. + passed to it as its only argument. Note that the global variable + MyBgworkerEntry points to a copy of the + BackgroundWorker structure passed at registration + time. bgw_sighup and bgw_sigterm are pointers to functions that will be installed as signal handlers for the new - process. + process. XXX: Can they be NULL? Once running, the process can connect to a database by calling @@ -104,6 +107,8 @@ the session is not connected to any particular database, but shared catalogs can be accessed. If username is NULL, the process will run as the superuser created during initdb. + BackgroundWorkerInitializeConnection can only be called once per background + process, it is not possible to switch databases.