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/>
