On Fri, Dec 25, 2015 at 8:57 PM, Craig Ringer <cr...@2ndquadrant.com> wrote:
> On 25 December 2015 at 19:45, Michael Paquier <michael.paqu...@gmail.com>
> wrote:
>> On Thu, Dec 24, 2015 at 5:57 PM, Dave Page <dp...@pgadmin.org> wrote:
>> > On Thu, Dec 24, 2015 at 2:14 AM, Craig Ringer <cr...@2ndquadrant.com>
>> > wrote:
>> >> On 22 December 2015 at 23:48, Alex Ignatov <a.igna...@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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to