Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Hmm, to what database would it connect?
>
> Well, it wouldn't. As of the patch I'm working on, it's okay to have
> PGPROC entries showing zero in databaseId. Normally they'd be backends
> that weren't done starting yet, but I see no reason the AV launcher
> couldn't stay that way indefinitely.
Makes sense.
> This would likely mean that the only thing it could safely do is seqscan
> pg_database, but that's all we need anyway, no?
Right.
> I suppose it might be a bit ugly to refactor InitPostgres enough to
> support this. I'm not sure which parts of that code we'd actually need
> to have run.
I'll have a look at that.
Are you going to commit the current patch? We can remove the hacks that
support autovacuum later. I was thinking that InitPostgres could be
split in two, with the first half ending just after
RelationCacheInitializePhase2. Then workers could figure out their
database names and go off on the second half; regular backends would
just call the two halves directly. That way, the launcher could use the
first half. (BTW I assume there is going to be an index on OID
available on pg_database after the shared relcache initialization?)
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support