On Thu, Feb 22, 2018 at 8:41 PM, Andres Freund <andres@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 <andres@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.
