Movatterモバイル変換

Postgres Pro can be extended to run user-supplied code in separate processes. Such processes are started, stopped and monitored bypostgres, which permits them to have a lifetime closely linked to the server's status. These processes are attached toPostgres Pro's shared memory area and have the option to connect to databases internally; they can also run multiple transactions serially, just like a regular client-connected server process. Also, by linking tolibpq they can connect to the server and behave like a regular client application.

Background workers can be initialized at the time thatPostgres Pro is started by including the module name inshared_preload_libraries. A module wishing to run a background worker can register it by callingRegisterBackgroundWorker(BackgroundWorker *worker) from its_PG_init() function. Background workers can also be started after the system is up and running by callingRegisterDynamicBackgroundWorker(BackgroundWorker *worker,BackgroundWorkerHandle **handle). UnlikeRegisterBackgroundWorker, which can only be called from within the postmaster process,RegisterDynamicBackgroundWorker must be called from a regular backend or another background worker.

The structureBackgroundWorker is defined thus:

typedef void (*bgworker_main_type)(Datum main_arg);typedef struct BackgroundWorker{    char        bgw_name[BGW_MAXLEN];    char        bgw_type[BGW_MAXLEN];    int         bgw_flags;    BgWorkerStartTime bgw_start_time;    int         bgw_restart_time;       /* in seconds, or BGW_NEVER_RESTART */    char        bgw_library_name[MAXPGPATH];    char        bgw_function_name[BGW_MAXLEN];    Datum       bgw_main_arg;    char        bgw_extra[BGW_EXTRALEN];    pid_t       bgw_notify_pid;} BackgroundWorker;

bgw_name andbgw_type are strings to be used in log messages, process listings and similar contexts.bgw_type should be the same for all background workers of the same type, so that it is possible to group such workers in a process listing, for example.bgw_name on the other hand can contain additional information about the specific process. (Typically, the string forbgw_name will contain the type somehow, but that is not strictly required.)

bgw_flags is a bitwise-or'd bit mask indicating the capabilities that the module wants. Possible values are:

bgw_start_time is the server state during whichpostgres should start the process; it can be one ofBgWorkerStart_PostmasterStart (start as soon aspostgres itself has finished its own initialization; processes requesting this are not eligible for database connections),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), andBgWorkerStart_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. Note that this setting only indicates when the processes are to be started; they do not stop when a different state is reached.

bgw_restart_time is the interval, in seconds, thatpostgres should wait before restarting the process in the event that it crashes. It can be any positive value, orBGW_NEVER_RESTART, indicating not to restart the process in case of a crash.

bgw_library_name is the name of a library in which the initial entry point for the background worker should be sought. The named library will be dynamically loaded by the worker process andbgw_function_name will be used to identify the function to be called. If calling a function in the core code, this must be set to"postgres".

bgw_function_name is the name of the function to use as the initial entry point for the new background worker. If this function is in a dynamically loaded library, it must be markedPGDLLEXPORT (and notstatic).

bgw_main_arg is theDatum argument to the background worker main function. This main function should take a single argument of typeDatum and returnvoid.bgw_main_arg will be passed as the argument. In addition, the global variableMyBgworkerEntry points to a copy of theBackgroundWorker structure passed at registration time; the worker may find it helpful to examine this structure.

On Windows (and anywhere else whereEXEC_BACKEND is defined) or in dynamic background workers it is not safe to pass aDatum by reference, only by value. If an argument is required, it is safest to pass an int32 or other small value and use that as an index into an array allocated in shared memory. If a value like acstring ortext is passed then the pointer won't be valid from the new background worker process.

bgw_extra can contain extra data to be passed to the background worker. Unlikebgw_main_arg, this data is not passed as an argument to the worker's main function, but it can be accessed viaMyBgworkerEntry, as discussed above.

bgw_notify_pid is the PID of a Postgres Pro backend process to which the postmaster should sendSIGUSR1 when the process is started or exits. It should be 0 for workers registered at postmaster startup time, or when the backend registering the worker does not wish to wait for the worker to start up. Otherwise, it should be initialized toMyProcPid.

Once running, the process can connect to a database by callingBackgroundWorkerInitializeConnection(char *dbname,char *username,uint32 flags) orBackgroundWorkerInitializeConnectionByOid(Oid dboid,Oid useroid,uint32 flags). This allows the process to run transactions and queries using theSPI interface. Ifdbname is NULL ordboid isInvalidOid, the session is not connected to any particular database, but shared catalogs can be accessed. Ifusername is NULL oruseroid isInvalidOid, the process will run as the superuser created duringinitdb. IfBGWORKER_BYPASS_ALLOWCONN is specified asflags it is possible to bypass the restriction to connect to databases not allowing user connections. IfBGWORKER_BYPASS_ROLELOGINCHECK is specified asflags it is possible to bypass the login check for the role used to connect to databases. A background worker can only call one of these two functions, and only once. It is not possible to switch databases.

Signals are initially blocked when control reaches the background worker's main function, and must be unblocked by it; this is to allow the process to customize its signal handlers, if necessary. Signals can be unblocked in the new process by callingBackgroundWorkerUnblockSignals and blocked by callingBackgroundWorkerBlockSignals.

Ifbgw_restart_time for a background worker is configured asBGW_NEVER_RESTART, or if it exits with an exit code of 0 or is terminated byTerminateBackgroundWorker, it will be automatically unregistered by the postmaster on exit. Otherwise, it will be restarted after the time period configured viabgw_restart_time, or immediately if the postmaster reinitializes the cluster due to a backend failure. Backends which need to suspend execution only temporarily should use an interruptible sleep rather than exiting; this can be achieved by callingWaitLatch(). Make sure theWL_POSTMASTER_DEATH flag is set when calling that function, and verify the return code for a prompt exit in the emergency case thatpostgres itself has terminated.

When a background worker is registered using theRegisterDynamicBackgroundWorker function, it is possible for the backend performing the registration to obtain information regarding the status of the worker. Backends wishing to do this should pass the address of aBackgroundWorkerHandle * as the second argument toRegisterDynamicBackgroundWorker. If the worker is successfully registered, this pointer will be initialized with an opaque handle that can subsequently be passed toGetBackgroundWorkerPid(BackgroundWorkerHandle *,pid_t *) orTerminateBackgroundWorker(BackgroundWorkerHandle *).GetBackgroundWorkerPid can be used to poll the status of the worker: a return value ofBGWH_NOT_YET_STARTED indicates that the worker has not yet been started by the postmaster;BGWH_STOPPED indicates that it has been started but is no longer running; andBGWH_STARTED indicates that it is currently running. In this last case, the PID will also be returned via the second argument.TerminateBackgroundWorker causes the postmaster to sendSIGTERM to the worker if it is running, and to unregister it as soon as it is not.

In some cases, a process which registers a background worker may wish to wait for the worker to start up. This can be accomplished by initializingbgw_notify_pid toMyProcPid and then passing theBackgroundWorkerHandle * obtained at registration time toWaitForBackgroundWorkerStartup(BackgroundWorkerHandle *handle,pid_t *) function. This function will block until the postmaster has attempted to start the background worker, or until the postmaster dies. If the background worker is running, the return value will beBGWH_STARTED, and the PID will be written to the provided address. Otherwise, the return value will beBGWH_STOPPED orBGWH_POSTMASTER_DIED.

A process can also wait for a background worker to shut down, by using theWaitForBackgroundWorkerShutdown(BackgroundWorkerHandle *handle) function and passing theBackgroundWorkerHandle * obtained at registration. This function will block until the background worker exits, or postmaster dies. When the background worker exits, the return value isBGWH_STOPPED, if postmaster dies it will returnBGWH_POSTMASTER_DIED.

Background workers can send asynchronous notification messages, either by using theNOTIFY command viaSPI, or directly viaAsync_Notify(). Such notifications will be sent at transaction commit. Background workers should not register to receive asynchronous notifications with theLISTEN command, as there is no infrastructure for a worker to consume such notifications.

The maximum number of registered background workers is limited bymax_worker_processes.