Re: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work - Mailing list pgsql-hackers

From Tom Lane
Subject Re: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work
Date
Msg-id 13782.1376145054@sss.pgh.pa.us
Whole thread Raw
In response to BackgroundWorkerInitializeConnection(NULL, ...) doesn't work  (Andrew Tipton <andrew@kiwidrew.com>)
List pgsql-hackers
Andrew Tipton <andrew@kiwidrew.com> writes:
> The documentation for 9.4 says, in the "Background Worker Processes"
> section:
> Once running, the process can connect to a database by calling
> BackgroundWorkerInitializeConnection(char *dbname, char *username). This
> allows the process to run transactions and queries using the SPI interface.
> If dbname is NULL, the session is not connected to any particular database,
> but shared catalogs can be accessed.

> Based on my quick read through InitPostgres() and postinit.c, it's not even
> clear that there's a way to access the shared catalogs without connecting
> to a specific database.

There is not, because you need e.g. pg_class and pg_attribute to be
available in order to open any relation whatsoever.  So this documentation
is just wrong.  A bg worker that chooses not to connect to a database
is shutting itself out of access to all relations.

There's been occasional talk of trying to refactor system catalogs into
separate shared and local components.  The main motivation for that was
to reduce the bloat from having many copies of pg_proc etc, but it could
conceivably also make it practical for processes to run with only a
view of the shared catalogs.  The work required seems far out of
proportion to these benefits, unfortunately ...
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work
Next
From: Tom Lane
Date:
Subject: Re: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work