Re: bg worker: patch 1 of 6 - permanent process
От | Robert Haas |
---|---|
Тема | Re: bg worker: patch 1 of 6 - permanent process |
Дата | |
Msg-id | AANLkTi=RmU+1wbeh8KLO_ADMKHy5yBnp23CuAZyE5VTH@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: bg worker: patch 1 of 6 - permanent process (Markus Wanner <markus@bluegap.ch>) |
Ответы |
Re: bg worker: general purpose requirements
|
Список | pgsql-hackers |
On Thu, Sep 16, 2010 at 1:20 PM, Markus Wanner <markus@bluegap.ch> wrote: > On 09/16/2010 04:26 PM, Robert Haas wrote: >> >> I agree. I've already said my piece on how I think that stuff would >> need to be reworked to be acceptable, so we might have to agree to >> disagree on those, especially if your goal is to get something >> committed that doesn't involve a major rewrite on your end. > > Just for clarification: you are referring to imessages and dynshmem here, > right? I agree that dynshmem needs to be reworked and rethought. And > imessages simply depends on dynshmem. Yes, I was referring to imessages and dynshmem. > If you are referring to the bgworker stuff, I'm not quite clear about what I > could do to make bgworker more acceptable. (Except perhaps for removing the > dependency on imessages). I'm not sure, either. It would be nice if there were a way to create a general facility here that we could then build various applications on, but I'm not sure whether that's the case. We had some back-and-forth about what is best for replication vs. what is best for vacuum vs. what is best for parallel query. If we could somehow conceive of a system that could serve all of those needs without introducing any more configuration complexity than what we have now, that would of course be very interesting. But judging by your comments I'm not very sure such a thing is feasible, so perhaps wait-and-see is the best approach. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: