> Hmm, the intention is that this code path mimics what the autovacuum > 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.
I'm pretty sure InitPostgres skips a bunch of stuff if 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.
