Thread: Re: Remove Windows crash dump support?
On 22 December 2015 at 22:50, Craig Ringer <craig@2ndquadrant.com> wrote:
Hi allBack in 2010 I submitted a small feature to allow the creation of minidumps when backends crashed; see commit dcb09b595f88a3bca6097a6acc17bf2ec935d55f .At the time Windows lacked useful support for postmortem debugging and crash-dump management in the operating system its self, especially for applications running as services. That has since improved considerably.The feature was also included in 9.4
Ahem. 9.1. This is what I get for multi-tasking between writing this and packaging an extension for 9.4.
On Tue, Dec 22, 2015 at 3:53 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
On 22 December 2015 at 22:50, Craig Ringer <craig@2ndquadrant.com> wrote:Hi allBack in 2010 I submitted a small feature to allow the creation of minidumps when backends crashed; see commit dcb09b595f88a3bca6097a6acc17bf2ec935d55f .At the time Windows lacked useful support for postmortem debugging and crash-dump management in the operating system its self, especially for applications running as services. That has since improved considerably.The feature was also included in 9.4Ahem. 9.1. This is what I get for multi-tasking between writing this and packaging an extension for 9.4.
In which version(s) of Windows was this improvement added? I think that's really the part that matters here, not necessarily which version of PostgreSQL.
Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Dec 22, 2015 at 3:53 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
>>> Back in 2010 I submitted a small feature to allow the creation of
>>> minidumps when backends crashed; see
>>> commit dcb09b595f88a3bca6097a6acc17bf2ec935d55f .
>>> At the time Windows lacked useful support for postmortem debugging and
>>> crash-dump management in the operating system its self, especially for
>>> applications running as services. That has since improved considerably.
> In which version(s) of Windows was this improvement added? I think that's
> really the part that matters here, not necessarily which version of
> PostgreSQL.
Even if it's all good in recent Windows, the impression I have is that an
awful lot of people are still running older versions, so I'd be pretty
hesitant to just drop the code. Also, AFAICS it's pretty self-contained
and hence not much of a drag on development. Is there any positive reason
to remove it? If the native facilities on newer Windows are better,
maybe we should teach the crash handler to install itself only on older
versions?
regards, tom lane
On 22.12.2015 18:28, Magnus Hagander wrote:
I think that you can debug crash dump since windbg exists.
Also I think that Postgres on Windows number of instalations is so tiny because people even today think that it is not so solid as unix version thats why you think that nobody use your code ;).
Today if my memory serves me right this code can not deal with buffer overflow. Am i right?
May be we need to add this functionality instead of drop support of it entirely?
Hi all!On Tue, Dec 22, 2015 at 3:53 PM, Craig Ringer <craig@2ndquadrant.com> wrote:On 22 December 2015 at 22:50, Craig Ringer <craig@2ndquadrant.com> wrote:Hi allBack in 2010 I submitted a small feature to allow the creation of minidumps when backends crashed; see commit dcb09b595f88a3bca6097a6acc17bf2ec935d55f .At the time Windows lacked useful support for postmortem debugging and crash-dump management in the operating system its self, especially for applications running as services. That has since improved considerably.The feature was also included in 9.4Ahem. 9.1. This is what I get for multi-tasking between writing this and packaging an extension for 9.4.In which version(s) of Windows was this improvement added? I think that's really the part that matters here, not necessarily which version of PostgreSQL.--
I think that you can debug crash dump since windbg exists.
Also I think that Postgres on Windows number of instalations is so tiny because people even today think that it is not so solid as unix version thats why you think that nobody use your code ;).
Today if my memory serves me right this code can not deal with buffer overflow. Am i right?
May be we need to add this functionality instead of drop support of it entirely?
-- Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
On 22 December 2015 at 23:48, Alex Ignatov <a.ignatov@postgrespro.ru> wrote:
I think that you can debug crash dump since windbg exists.
Nobody in their right mind uses windbg though. Visual Studio is really where it's at and the Express versions make it much more practical.
You can't even install Debugging Tools for Windows and Windbg standalone anymore.
Also I think that Postgres on Windows number of instalations is so tiny because people even today think that it is not so solid as unix version thats why you think that nobody use your code ;).
I disagree. Windows Pg users are often at bigger companies and don't talk about PostgreSQL as much. Often for fear of reprisals from other database vendors they have ongoing relationships with. At least that's been my experience and I'm sure EDB folks will concur.
Today if my memory serves me right this code can not deal with buffer overflow. Am i right?
Stack overflow?
No, it can't. The stack has to be somewhat sane.
May be we need to add this functionality instead of drop support of it entirely
Why? I've never seen any sign anybody has used it, ever.
On 12/23/2015 06:14 PM, Craig Ringer wrote: > On 22 December 2015 at 23:48, Alex Ignatov <a.ignatov@postgrespro.ru > <mailto:a.ignatov@postgrespro.ru>> wrote: > > I think that you can debug crash dump since windbg exists. > > > Nobody in their right mind uses windbg though. Visual Studio is really > where it's at and the Express versions make it much more practical. > > You can't even install Debugging Tools for Windows and Windbg standalone > anymore. > > Also I think that Postgres on Windows number of instalations is so > tiny because people even today think that it is not so solid as > unix version thats why you think that nobody use your code ;). > > > I disagree. Windows Pg users are often at bigger companies and don't > talk about PostgreSQL as much. Often for fear of reprisals from other > database vendors they have ongoing relationships with. At least that's > been my experience and I'm sure EDB folks will concur. I can speak from experience as well that Windows is unfortunately one of our larger installations. The fact is, many people run PostgreSQL on Windows and many never speak of it. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is basically telling the world you can't control your own emotions, so everyone else should do it for you.
On 22 December 2015 at 23:46, Tom Lane <tgl@sss.pgh.pa.us> wrote:
-- > In which version(s) of Windows was this improvement added?
Vista and Server 2008 (original, not R2).
Win7 and Server 2003 are already irrelevant now, and will be absurdly so by the time Pg 9.6 comes out.
The windows feature works better than the in-application crash dump. It can limit the number of dumps, for one thing, and it doesn't require a sane and intact stack to work.
Even if it's all good in recent Windows, the impression I have is that an
awful lot of people are still running older versions, so I'd be pretty
hesitant to just drop the code.
Yeah, if it was new in Win2012 I'd agree, but it's been around since 2008.
Also, AFAICS it's pretty self-contained
and hence not much of a drag on development. Is there any positive reason
to remove it?
Not really. It also does nothing by default, so it's pretty harmless and mostly dead code.
I just thought it was worth bringing up that there's a better way to do it now and nobody seems to use it anyway.
On Thu, Dec 24, 2015 at 2:14 AM, Craig Ringer <craig@2ndquadrant.com> wrote: > On 22 December 2015 at 23:48, Alex Ignatov <a.ignatov@postgrespro.ru> wrote: > >> >> I think that you can debug crash dump since windbg exists. > > > Nobody in their right mind uses windbg though. Visual Studio is really where > it's at and the Express versions make it much more practical. > > You can't even install Debugging Tools for Windows and Windbg standalone > anymore. > >> >> Also I think that Postgres on Windows number of instalations is so tiny >> because people even today think that it is not so solid as unix version >> thats why you think that nobody use your code ;). > > > I disagree. Windows Pg users are often at bigger companies and don't talk > about PostgreSQL as much. Often for fear of reprisals from other database > vendors they have ongoing relationships with. At least that's been my > experience and I'm sure EDB folks will concur. In my experience PG isn't used much in production on Windows in bigger companies. It's used a *lot* (and is quite probably the most frequently downloaded build from EDB or postgresql.org) as an embedded database in some applications, and for development/test. There are a huge number of Windows PostgreSQL users out there. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Dec 24, 2015 at 5:57 PM, Dave Page <dpage@pgadmin.org> wrote: > On Thu, Dec 24, 2015 at 2:14 AM, Craig Ringer <craig@2ndquadrant.com> wrote: >> On 22 December 2015 at 23:48, Alex Ignatov <a.ignatov@postgrespro.ru> wrote: >> >>> >>> I think that you can debug crash dump since windbg exists. >> >> >> Nobody in their right mind uses windbg though. Visual Studio is really where >> it's at and the Express versions make it much more practical. Well, FWIW, I have been working lately on a bug hidden in a custom background worker on Windows that crashed in some weird way with a 0x000000C5, and while I have a reproducible test case I have not yet found the time to look at it yet but I would think that this is generating a core dump, and that I will need to use windbg for that. Hence count me on the -1 team. >> You can't even install Debugging Tools for Windows and Windbg standalone >> anymore. >> >>> >>> Also I think that Postgres on Windows number of instalations is so tiny >>> because people even today think that it is not so solid as unix version >>> thats why you think that nobody use your code ;). >> >> >> I disagree. Windows Pg users are often at bigger companies and don't talk >> about PostgreSQL as much. Often for fear of reprisals from other database >> vendors they have ongoing relationships with. At least that's been my >> experience and I'm sure EDB folks will concur. > > In my experience PG isn't used much in production on Windows in bigger > companies. Well, there is indeed not much, but it is used. At least I work for one and Postgres is embedded in a couple of products on Windows. > It's used a *lot* (and is quite probably the most > frequently downloaded build from EDB or postgresql.org) as an embedded > database in some applications, and for development/test. There are a > huge number of Windows PostgreSQL users out there. And they don't those ones. -- Michael
On 25 December 2015 at 19:45, Michael Paquier <michael.paquier@gmail.com> wrote:
On Thu, Dec 24, 2015 at 5:57 PM, Dave Page <dpage@pgadmin.org> wrote:
> On Thu, Dec 24, 2015 at 2:14 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
>> On 22 December 2015 at 23:48, Alex Ignatov <a.ignatov@postgrespro.ru> wrote:
>>
>>>
>>> I think that you can debug crash dump since windbg exists.
>>
>>
>> Nobody in their right mind uses windbg though. Visual Studio is really where
>> it's at and the Express versions make it much more practical.
Well, FWIW, I have been working lately on a bug hidden in a custom
background worker on Windows that crashed in some weird way with a
0x000000C5, and while I have a reproducible test case I have not yet
found the time to look at it yet but I would think that this is
generating a core dump, and that I will need to use windbg for that.
Hence count me on the -1 team.
Huh?
You can use VS Express to debug a core dump. Per links upthread you can get the platform to generate core dumps for you. No windbg required.
If you want to torture yourself using windbg go ahead, but it really isn't necessary, you can use a sane debugger.
On Thu, Dec 24, 2015 at 7:48 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
On 22 December 2015 at 23:46, Tom Lane <tgl@sss.pgh.pa.us> wrote:> In which version(s) of Windows was this improvement added?Vista and Server 2008 (original, not R2).Win7 and Server 2003 are already irrelevant now, and will be absurdly so by the time Pg 9.6 comes out.
Sure, but I think still there could be developers out there or some users
of PostgreSQL who will still be using some such systems.
The windows feature works better than the in-application crash dump.
Have you used this feature of Windows and does it display the call stack
or the information better than what PostgreSQL already has, if you have
any saved dump, that others can also see, that might be useful?
Unfortunately, I am still using Win7, so not able to test using this
new feature.
On Wed, Dec 23, 2015 at 6:14 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
On 22 December 2015 at 23:48, Alex Ignatov <a.ignatov@postgrespro.ru> wrote:I think that you can debug crash dump since windbg exists.Nobody in their right mind uses windbg though. Visual Studio is really where it's at and the Express versions make it much more practical.
Just FYI. Most developers of MS server (OS/SQL Server) team use windbg. Windbg was my only debugger when I worked there and I never used Visual Studio.
You can't even install Debugging Tools for Windows and Windbg standalone anymore.Also I think that Postgres on Windows number of instalations is so tiny because people even today think that it is not so solid as unix version thats why you think that nobody use your code ;).I disagree. Windows Pg users are often at bigger companies and don't talk about PostgreSQL as much. Often for fear of reprisals from other database vendors they have ongoing relationships with. At least that's been my experience and I'm sure EDB folks will concur.Today if my memory serves me right this code can not deal with buffer overflow. Am i right?Stack overflow?No, it can't. The stack has to be somewhat sane.May be we need to add this functionality instead of drop support of it entirelyWhy? I've never seen any sign anybody has used it, ever.--
On Fri, Dec 25, 2015 at 8:57 PM, Craig Ringer <craig@2ndquadrant.com> wrote: > On 25 December 2015 at 19:45, Michael Paquier <michael.paquier@gmail.com> > wrote: >> >> On Thu, Dec 24, 2015 at 5:57 PM, Dave Page <dpage@pgadmin.org> wrote: >> > On Thu, Dec 24, 2015 at 2:14 AM, Craig Ringer <craig@2ndquadrant.com> >> > wrote: >> >> On 22 December 2015 at 23:48, Alex Ignatov <a.ignatov@postgrespro.ru> >> >> wrote: >> >> >> >>> >> >>> I think that you can debug crash dump since windbg exists. >> >> >> >> >> >> Nobody in their right mind uses windbg though. Visual Studio is really >> >> where >> >> it's at and the Express versions make it much more practical. >> >> Well, FWIW, I have been working lately on a bug hidden in a custom >> background worker on Windows that crashed in some weird way with a >> 0x000000C5, and while I have a reproducible test case I have not yet >> found the time to look at it yet but I would think that this is >> generating a core dump, and that I will need to use windbg for that. >> Hence count me on the -1 team. > > > Huh? > > You can use VS Express to debug a core dump. Per links upthread you can get > the platform to generate core dumps for you. No windbg required. > > If you want to torture yourself using windbg go ahead, but it really isn't > necessary, you can use a sane debugger. Well, coming back to my story with the background worker I have been debugging. Creating PGDATA/crashdumps has allowed me to easily get a dump, and then I had a look at it using my Win7 workstation because VS was not available in the server where the crash happened, which was a 2k12 server btw. So I think that it is still useful for debugging code paths running custom code, even if we consider Postgres as rock-solid on Windows. In short, -1. -- Michael
On 2016-01-04 16:39:22 +0900, Michael Paquier wrote: > So I think that it is still useful for debugging code > paths running custom code, even if we consider Postgres as rock-solid > on Windows. Given the state of e.g. the socket using code for windows I personally certainly don't consider it rock solid. Either way, since there were a few people interested in keeping the support, and nobody really had any arguments besids "seems unused" for removing it, this seems like a pretty clear cut case. Andres