Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)
От | Tom Lane |
---|---|
Тема | Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files) |
Дата | |
Msg-id | 29987.1290448481@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re: Proposed Windows-specific change: Enable crash
dumps (like core files)
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.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. 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. regards, tom lane
В списке pgsql-hackers по дате отправления: