On Thu, Feb 22, 2018 at 8:41 PM, Andres Freund <and...@anarazel.de> wrote:

> On 2018-02-22 20:30:52 +0100, Magnus Hagander wrote:
> > On Thu, Feb 22, 2018 at 8:24 PM, Andres Freund <and...@anarazel.de>
> wrote:
> > > I suspect I'm going to get some grief for this, but I think the time
> has
> > > come to bite the bullet and support changing databases in the same
> > > process...
> > >
> >
> > Hey, I can't even see the goalposts anymore :P
> Hah. I vote for making this a hard requirement :P

Hah! Are you handing out binoculars? :)

> > Are you saying this should be done *in general*, or specifically for
> > background workers? I'm assuming you mean the general case?
> I'd say bgworkers first. It's a lot clearer how to exactly do it
> there. Refactoring the mainloop handling in PostgresMain() would be a
> bigger task.
Yeah, it'd probably be easier. I don't know exactly what it'd involve but
clearly less.

In this particular case that would at least phase 1 simplify it because
we'd only need one process instead of worker/launcher. However, if we'd
ever want to parallellize it -- or any other process of the style, like
autovacuum -- you'd still need a launcher+worker combo. So making that
particular scenario simpler might be worthwhile on it's own.

> > That would be very useful, but is probably a fairly non-trivial task
> > (TM).
> I'm not actually that sure it is. We have nearly all the code, I
> think. Syscache inval, ProcKill(), and then you're nearly ready to do
> the normal connection dance again.

I'll take your word for it :) I haven't dug into that part.

 Magnus Hagander
 Me: https://www.hagander.net/ <http://www.hagander.net/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

Reply via email to