Re: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work
| От | Andrew Tipton |
|---|---|
| Тема | Re: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work |
| Дата | |
| Msg-id | CA+M2pVULSPLFK7JUqf0u1XYX-09x3s6kVUBSD8-zkvrX5hsx1w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On Sat, Aug 10, 2013 at 10:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:> Hmm, the intention is that this code path mimics what the autovacuumI'm pretty sure InitPostgres skips a bunch of stuff if
> launcher does to establish its connection. It did work at some point;
> maybe I broke this before commit. I will give it a look next week.
IsAutoVacuumLauncherProcess(). If you just want to make an environment
equivalent to that process's, maybe those tests should be replaced with
"if (dbname == NULL)". But the claim that you have access to shared
catalogs in this state is still wrong.
I've written up a quick proof-of-concept that splits InitPostgres(dbname, username) into two phases; InitPostgresPhase1() is equivalent to what was set up prior to the autovacuum launcher bailing out, while InitPostgresPhase2(dbname, username) contains all of the authentication and database selection logic.
After calling InitPostgresPhase1(), certain accesses to shared catalogs *do* work. For example, ClientAuthentication() searches the AUTHNAME syscache. Later, a call to InitPostgresPhase2() with the dbname and username brings things to a state where normal SPI can be used. This behaviour would be quite useful for certain classes of bgworker.
Documentation-wise, it would be helpful to specify precisely what is/isn't allowed in this "shared catalogs only" mode.
See the attached patch -- which is just a proof-of-concept -- for the details.
Regards,
Andrew Tipton
Andrew Tipton
Вложения
В списке pgsql-hackers по дате отправления: