Re: Streaming replication and postmaster signaling - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Streaming replication and postmaster signaling |
Date | |
Msg-id | 603c8f071001071145x16ab500et1ee5d3ea9c7e20ce@mail.gmail.com Whole thread Raw |
In response to | Re: Streaming replication and postmaster signaling (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Streaming replication and postmaster signaling
Re: Streaming replication and postmaster signaling |
List | pgsql-hackers |
On Thu, Jan 7, 2010 at 2:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> That may well be so, but adding another one is not going to improve >> the situation even a little bit. I don't think what you're saying >> weakens in the slightest the argument that I was making, namely, that >> if this isn't committed RSN it should be postponed to 8.6. Do you >> disagree? > > Well, the argument to my mind is about a suitable value of "RSN". > I think you were stating that we should bounce SR if it's not committed > before the final commitfest starts (ie, next week). I think we can give > it more slack than that. Maybe the end of the fest (where the length of > the fest is determined by the other open patches)? We did that for 8.4 and I don't think it worked very well. I think we should have a HARD cutoff of one month for this CommitFest, just as we have had for the other ones this cycle. Anything we can't get through by February 15th and isn't a release-blocker should just be pushed out to 8.6. It is not as if we have a big backlog of patches carried over from previous CommitFests; we have only two of any size, that I am aware of: SR and listen/notify. Anything else that is adversely affected by this policy is something that was submitted for only the last CommitFest, and as long as we give those patches a fair review and good feedback before bouncing them, I don't think we should feel bad about postponing the ones that are not ready. If you accept that principle then the question is whether SR should have a different cut-off than the other patches in the CommitFest. I was being a bit coy about my position on that topic in my original message and I'm still of two minds about it, but your mind-reading is basically correct. On the one hand, imposing an earlier deadline might be viewed as moving the goalposts and I'm generally a big opponent of that. On the other hand, assuming that the amount of community time Heikki gets is independent of what he's working on, shooting SR through the head sooner means more time to stabilize HS, which means an earlier release, and since there seems to be a substantial danger that the release will be late no matter what we do, I am tempted to say we should clamp down and go into damage control mode sooner rather than later. I am really reluctant to go through another cycle of giving a big feature as much time as humanly possible before bouncing it, and then bouncing it anyway, and I fear that is what will happen. I don't believe this patch has had a major rewrite since it was submitted for the September CommitFest, and if 4 months hasn't been enough time to get it committed, then why do we think the magic number is 5 rather than 6 or 8 or anything else? If someone has a concrete answer to that question, I am all ears, but I feel like we're operating mostly on hope. ...Robert
pgsql-hackers by date: