Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On Mon, Nov 22, 2010 at 18:54, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 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.
>
> Well, if we're going to hand out prebuilt DLLs to people, we can do that
> without having back-patched the code officially.  But more to the point
> is that it's not clear that we're going to end up with a contrib module
> at all going forward (a core feature would clearly be a lot more
> reliable), and I really do not wish to get involved with maintaining two
> independent versions of this code.

I think the reasonable options are either "don't backpatch at all" or
"backpatch the same way as we put it in HEAD, which is probably
included in backend". I agree that sticking it in contrib is a
half-measure that we shouldn't do.

*IF* we go with a contrib module for 9.1 as well, we could backpatch
as contrib module, but I think that's the only case.

> This argument seems to boil down to "we have to have this yesterday",
> which I don't buy for a minute.  If it's as critical as that, why did
> it take this long for someone to write it?  I do NOT agree that this
> feature is important enough to justify a free pass around our normal
> management and quality assurance processes.

Agreed.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/