Re: Disabled features on Hot Standby - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Disabled features on Hot Standby |
Date | |
Msg-id | CA+TgmoY6mdyJQDe_kkJw34BaXS85iCESLapv_dqUSNBczg2A+A@mail.gmail.com Whole thread Raw |
In response to | Re: Disabled features on Hot Standby (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Responses |
Re: Disabled features on Hot Standby
|
List | pgsql-hackers |
On Fri, Jan 13, 2012 at 5:37 PM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> Well, I disagree. The fact that all-visible info can't be trusted in >> standby mode is a problem that has existed since Hot Standby was >> committed, and I don't feel obliged to fix it just because I was >> involved in developing a new feature that happens to rely on > > I'm very sorry to read that, because I sure feel like that's exactly > what us non commiters are asked to be doing when cooking any patch. There is obviously room for disagreement over what should or should not be within the scope of any particular development project, and we may not always agree on that. However, I do try to act in good faith and apply, as much as I can, the same standard to other people's patches as I do to my own. In general, when I ask for the scope of something to be expanded, I try to limit myself to something that I feel can be accomplished in a day or two of development and which are closely related to the core of what the patch is about. There are exceptions, of course, where I feel that more than that is needed, but there are also many examples on file of me arguing for a narrower scope - either that an already-written patch should be divided into pieces so that the uncontroversial pieces can be committed, or that a project need not include every element that anyone wants in order to be acceptable. I try very hard to be sensitive to the fact that non-committers also have stuff they want to get done, which is why I am one of the most prolific committers of the work of non-committers, even extending in numerous instances (most recently, today) to expending rather large amounts of time rewriting stuff that neither I nor my employer have a huge stake in to reach the quality of code that I think is needed for commit, or to satisfy the objections of other community members that I may not personally share. In this particular case, I am not even the person who committed the patch. Tom committed index-only scans well before I thought it was ready for prime time, and then did a whole lot of work to improve it afterwards. Even now, I believe there are significant issues remaining. There is no EXPLAIN support (for which I supported a patch today); the statistics might need work (as Magnus complained about in response to my EXPLAIN patch); we don't yet support index-only quals (i.e. even though you know you'll eventually need the heap tuple, evaluate the quals you can using just the index tuple in the hopes of avoiding some heap fetches); and I'm pretty worried that we'll run across cases where too much of the heap is not-all-visible and we either don't use index only scans or we use them but they don't perform well - a problem which I suspect will require adjustment of our vacuuming algorithm to avoid. With the exception of EXPLAIN support which I think is merely an oversight, all of those issues, including the problems in Hot Standby mode, remain because nobody knows exactly what we ought to do to fix them. When somebody figures it out, I predict they'll get fixed pretty quickly. Now, whether or not that will be in time for 9.2, or whether I'll be the one to write the code, I don't know. But in the meantime, there are really only two choices here: we can understand that the feature we have has some limitations, or we can revert it. Considering the amount of time that was put into it, particular by Tom, I can't imagine that we really want to revert it, but then again I'm relatively shocked that I'm being asked, one day before final CommitFest starts, to drop everything and work on a limitation that I thought had been well-understood by everyone for three years and that it's not clear we know how to lift. It may be that I didn't do a sufficiently good job communicating that this limitation was bound to exist, and I apologize for that. I did mention it on-list multiple times, as did Heikki, and I thought it was understood, but apparently not. If people who didn't object to committing the patch would have done so had they realized this, and don't feel that I made it clear enough, I am sincerely sorry. I would have made the same argument then that I am making now, but at least we would have hashed it out one way or the other before moving forward. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: