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 and
   <structfield>bgw_function_name</structfield> will be used to identify the
   function to be called.  If calling a function in the core code, this must
   be set to <literal>"postgres"</literal>.
  </para>

  <para>
   <structfield>bgw_function_name</structfield> 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 marked
   <literal>PGDLLEXPORT</literal> (and not <literal>static</literal>).
  </para>

  <para>
   <structfield>bgw_main_arg</structfield> is the <type>Datum</type> argument
   to the background worker main function.  This main function should take a
   single argument of type <type>Datum</type> and return <type>void</type>.
   <structfield>bgw_main_arg</structfield> will be passed as the argument.
   In addition, the global variable <literal>MyBgworkerEntry</literal>
   points to a copy of the <structname>BackgroundWorker</structname> structure
   passed at registration time; the worker may find it helpful to examine
   this structure.
  </para>

  <para>
   On Windows (and anywhere else where <literal>EXEC_BACKEND</literal> is
   defined) or in dynamic background workers it is not safe to pass a
   <type>Datum</type> 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 a <type>cstring</type>
   or <type>text</type> is passed then the pointer won't be valid from the
   new background worker process.
  </para>

  <para>
   <structfield>bgw_extra</structfield> can contain extra data to be passed
   to the background worker.  Unlike <structfield>bgw_main_arg</structfield>, this data
   is not passed as an argument to the worker's main function, but it can be
   accessed via <literal>MyBgworkerEntry</literal>, as discussed above.
  </para>

  <para>
   <structfield>bgw_notify_pid</structfield> is the PID of a PostgreSQL
   backend process to which the postmaster should send <literal>SIGUSR1</literal>
   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 to <literal>MyProcPid</literal>.
  </para>

  <para>Once running, the process can connect to a database by calling
   <function>BackgroundWorkerInitializeConnection(<parameter>char *dbname</parameter>, <parameter>char *username</parameter>, <parameter>uint32 flags</parameter>)</function> or
   <function>BackgroundWorkerInitializeConnectionByOid(<parameter>Oid dboid</parameter>, <parameter>Oid useroid</parameter>, <parameter>uint32 flags</parameter>)</function>.
   This allows the process to run transactions and queries using the
   <literal>SPI</literal> interface.  If <varname>dbname</varname> is NULL or
   <varname>dboid</varname> is <literal>InvalidOid</literal>, the session is not connected
   to any particular database, but shared catalogs can be accessed.
   If <varname>username</varname> is NULL or <varname>useroid</varname> is
   <literal>InvalidOid</literal>, the process will run as the superuser created
   during <command>initdb</command>. If <literal>BGWORKER_BYPASS_ALLOWCONN</literal>
   is specified as <varname>flags</varname> it is possible to bypass the restriction
   to connect to databases not allowing user connections.
   If <literal>BGWORKER_BYPASS_ROLELOGINCHECK</literal> is specified as
   <varname>flags</varname> 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.
  </para>