Re: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work

On Sat, Aug 10, 2013 at 10:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > 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.

Regards,
Andrew Tipton