Re: disposition of remaining patches
От | Daniel Farina |
---|---|
Тема | Re: disposition of remaining patches |
Дата | |
Msg-id | AANLkTi=JVBLoRqpy7AsKHw5RqGG6Xf0HMdox40C8KdmM@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: disposition of remaining patches (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: disposition of remaining patches
|
Список | pgsql-hackers |
On Fri, Feb 25, 2011 at 4:43 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Feb 25, 2011 at 3:14 AM, Daniel Farina <daniel@heroku.com> wrote: >> On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith <greg@2ndquadrant.com> wrote: >>> Robert Haas wrote: >>>>> >>>>> 2. Synchronous replication. Splitting up this patch has allowed some >>> On top of 4 listed reviewers I know Dan Farina is poking at the last update, >>> so we may see one more larger report on top of what's already shown up. And >>> Jaime keeps kicking the tires too. What Simon was hoping is that a week of >>> others looking at this would produce enough feedback that it might be >>> possible to sweep the remaining issues up soon after he's back. It looks to >>> me like that's about when everything else that's still open will probably >>> settle too. >> >> Besides some of the fixable issues, I am going to have to echo >> Robert's sentiments about a few kinks that go beyond mechanism in the >> syncrep patch: in particular, it will *almost* solve the use case I >> was hoping to solve: a way to cleanly perform planned switchovers >> between machines with minimal downtime and no lost data. But there are >> a couple of holes I have thought of so far: > > Well, just because the patch doesn't solve every use case isn't a > reason not to go forward with it - we can always add more options > later - but I have to admit that I'm kind of alarmed about the number > of bugs reported so far. True: the relevance of any use case to acceptance is up to some debate. I haven't thought about how to remedy this, just thinking aloud about a problem I would have as-is, and is important to me. It is true that later accretion of options can occur, but sometimes the initial choice of semantics can make growing those easier or harder. I haven't yet thought ahead as to how the current scheme would impact that. I know I got hit by a backend synchronization (in the sense of locks, etc) bugs; do you think it is possible yours (sending SIGSTOP) could be the same root cause? I haven't followed all the other bugs cleared up by inspection. -- fdr
В списке pgsql-hackers по дате отправления: