Re: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work
От | Tom Lane |
---|---|
Тема | Re: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work |
Дата | |
Msg-id | 13782.1376145054@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BackgroundWorkerInitializeConnection(NULL, ...) doesn't work (Andrew Tipton <andrew@kiwidrew.com>) |
Список | 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 по дате отправления: