Re: Disabled features on Hot Standby

On Fri, Jan 13, 2012 at 5:37 PM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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