Re: WIP patch for parallel pg_dump - Mailing list pgsql-hackers

On Thu, Dec 2, 2010 at 9:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Umm, nobody has attributed ridiculousness to anyone. Please don't put
>> words in my mouth. But I think this is a perfectly reasonable discussion
>> to have. Nobody gets to come along and get the features they want
>> without some sort of consensus, not me, not you, not Joachim, not Tom.
>
> In particular, this issue *has* been discussed before, and there was a
> consensus that preserving dump consistency was a requirement.  I don't
> think that Joachim gets to bypass that decision just by submitting a
> patch that ignores it.

Well, the discussion that Joachim linked too certainly doesn't have
any sort of clear consensus that that's the only way to go.  In fact,
it seems to be much closer to the opposite consensus.  Perhaps there
is some OTHER time that this has been discussed where "synchronization
is a hard requirement" was the consensus.  There's an old saw that the
nice thing about standards is there are so many to choose from, and
the same thing can certainly be said about -hackers discussions on any
particular topic.

I actually think that the phrase "this has been discussed before and
rejected" should be permanently removed from our list of excuses for
rejecting a patch.  Or if we must use that excuse, then I think a link
to the relevant discussion is a must, and the relevant discussion had
better reflect the fact that $TOPIC was in fact rejected.  It seems to
me that in at least 50% of cases, someone comes back and says one of
the following things:

1. I searched the archives and could find no discussion along those lines.
2. I read that discussion and it doesn't appear to me that it reflects
a rejection of this idea.  Instead what people seemed to be saying was
X.
3. At the time that might have been true, but what has changed in the
meanwhile is X.

In short, the problem with referring to previous discussions is that
our memories grow fuzzy over time.  We remember that an idea was not
adopted, but not exactly why it wasn't adopted.  We reject a new patch
with a good implementation of $FEATURE because an old patch was badly
done, or fell down on some peripheral issue, or just never got done.
Veteran backend hackers understand the inevitable necessity of arguing
about what consensus is actually reflected in the archives and whether
it's still relevant, but new people can be (and frequently are) put
off by it; and even for experienced contributors, it does little to
advance the dialogue.  Hmm, according to so-and-so's memory, sometime
in the fourteen-year-history of the project someone didn't like this
idea, or maybe a similar one.  Whee, time to start Googling.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company