Re: Re: [COMMITTERS] pgsql: Use a latch to make startup process wake up and replay - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Re: [COMMITTERS] pgsql: Use a latch to make startup process wake up and replay |
Date | |
Msg-id | AANLkTin6ooWTeaXeX1T=x6VNTN8dQnambjjRrpaDydVR@mail.gmail.com Whole thread Raw |
In response to | Re: Re: [COMMITTERS] pgsql: Use a latch to make startup process wake up and replay (Simon Riggs <simon@2ndQuadrant.com>) |
Responses |
Re: Re: [COMMITTERS] pgsql: Use a latch to make startup
process wake up and replay
Re: Re: [COMMITTERS] pgsql: Use a latch to make startup process wake up and replay |
List | pgsql-hackers |
On Wed, Sep 15, 2010 at 1:30 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Wed, 2010-09-15 at 12:45 -0400, Robert Haas wrote: >> On Wed, Sep 15, 2010 at 11:24 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> > I agree that asking people to stop work is not OK. However, I haven't >> > asked for development work to stop, only that commits into that area >> > stop until proper debate has taken place. Those might be minor commits, >> > but they might not. Had I made those commits, they would have been >> > called premature by others also. >> >> I do not believe that Heikki has done anything inappropriate. We've >> spent weeks discussing the latch facility and its various >> applications. > > Sounds reasonable, but my comments were about this commit, not the one > that happened on Saturday. This patch was posted about 32 hours ago, and > the commit need not have taken place yet. If I had posted such a patch > and committed it knowing other work is happening in that area we both > know that you would have objected. I've often felt that we ought to have a bit more delay between when committers post patches and when they commit them. I was told 24 hours and I've seen cases where people haven't even waited that long. On the other hand, if we get to strict about it, it can easily get to the point where it just gets in the way of progress, and certainly some patches are far more controversial than others. So I don't know what the best thing to do is. Still, I have to admit that I feel fairly positive about the direction we're going with this particular patch. Clearing away these peripheral issues should make it easier for us to have a rational discussion about the core issues around how this is going to be configured and actually work at the protocol level. > It's not actually a major issue, but at some point I have to ask for no > more commits, so Fujii and I can finish our patches, compare and > contrast, so the best ideas can get into Postgres. I don't think anyone is prepared to agree to that. I think that everyone is prepared to accept a limited amount of further delay in pressing forward with the main part of sync rep, but I expect that no one will be willing to freeze out incremental improvements in the meantime, even if it does induce a certain amount of rebasing. It's also worth noting that Fujii Masao's patch has been around for months, and yours isn't finished yet. That's not to say that we don't want to consider your ideas, because we do: and you've had more than your share of good ones. At the same time, it would be unfair and unreasonable to expect work on a patch that is done, and has been done for some time, to wait on one that isn't. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
pgsql-hackers by date: