On Mon, Nov 22, 2010 at 12:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I don't see why an upgrading aid would be worthy of back-patching, but
>> not a debugging aid. I'd certainly prioritize those in the other
>> order.
>
> I think the sort of upgrading aid Peter has in mind is the kind where
> it's entirely useless if it's not back-patched, because it has to run in
> the pre-upgraded server. We've discussed such things before in the
> context of in-place upgrade, though I believe there have been no actual
> instances as yet.
>
> I'm not really sure why we're even considering the notion of
> back-patching this item. Doing so would not fit with any past practice
> or agreed-on project management practices, not even under our lax
> standards for contrib (and I keep hearing people claim that contrib
> is or should be as trustworthy as core, anyway). Since when do we
> back-patch significant features that have not been through a beta test
> cycle?
I am as conservative about back-patching as anybody here, but
debugging on Windows is not an easy thing to do, and I strongly
suspect we are going to point people experiencing crashes on Windows
to this code whether it's part of our official distribution or not. I
don't see what we get out of insisting that people install it
separately. This is a tool that is only intended to be used when
PostgreSQL is CRASHING, so arguing that we shouldn't include the code
because it might not be stable doesn't carry much water AFAICS. As
far as I understand it, we don't back-patch new features because of
the risk of breaking things, but in this case refusing to back-patch
the code seems more likely to prevent adequate diagnosis of what is
already broken.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company