Message-ID: <508631F7.9040607@ringerc.id.au>
Date: Tue, 23 Oct 2012 13:58:15 +0800
From: Craig Ringer <ringerc@ringerc.id.au>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121016 Thunderbird/16.0.1
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: raghu ram <raghuchennuru@gmail.com>, pgsql-admin@postgresql.org,
	pgsql-general <pgsql-general@postgresql.org>
Subject: Re: [ADMIN] Streaming Replication Server Crash
References: 
 <CALnrrJQ81icyt7EpzPwPuXPK0SbSv4+C8uyA=6Nwqh+mLw2hOw@mail.gmail.com>
	<5084EF7E.5080809@ringerc.id.au> <27094.1350910358@sss.pgh.pa.us>
	<50862525.5060904@ringerc.id.au> <3067.1350969631@sss.pgh.pa.us>
In-Reply-To: <3067.1350969631@sss.pgh.pa.us>
Content-Type: multipart/alternative;
	boundary="------------000402020408050807040308"

This is a multi-part message in MIME format.
--------------000402020408050807040308
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 10/23/2012 01:20 PM, Tom Lane wrote:
>
> This isn't the first time I've wondered exactly which signal was meant
> in a postmaster child-crash report.  Seems like it might be worth
> expending some code on a symbolic translation, instead of just printing
> the number.  That'd be easy enough (for common signal names) on Unix,
> but has anyone got a suggestion how we might do something useful on
> Windows?

Here's a typical Windows exception:


2012-10-04 14:29:08 CEST LOG:  server process (PID 1416) was terminated
by exception 0xC0000005

2012-10-04 14:29:08 CEST HINT:  See C include file "ntstatus.h" for a
description of the hexadecimal value.


These codes can be translated with FormatMessage:

 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms679351(v=vs.85).aspx
<http://msdn.microsoft.com/en-us/library/windows/desktop/ms679351%28v=vs.85%29.aspx>
  http://support.microsoft.com/kb/259693

FormatMessage may not be safe to perform in the context of a munged heap
or some other failure conditions, so you probably don't want to do it
from a crash handler. It is safe for the postmaster to do it based on
the exception code it gets from the dying backend, though.

I'd say the best option is for the postmaster to print the
FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER|FORMAT_MESSAGE_FROM_SYSTEM|FORMAT_MESSAGE_FROM_HMODULE,
...) output when it sees the exception code from the dying backend.

RtlNtStatusToDosError may also be of interest:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680600(v=vs.85).aspx
<http://msdn.microsoft.com/en-us/library/windows/desktop/ms680600%28v=vs.85%29.aspx>
... but it's in Winternl.h so it's not guaranteed to exist / be
compatible between versions and can only be accessed via runtime dynamic
linking. Not ideal.

--
Craig Ringer

--------------000402020408050807040308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 10/23/2012 01:20 PM, Tom Lane wrote:<br>
    </div>
    <blockquote cite="mid:3067.1350969631@sss.pgh.pa.us" type="cite"><br>
      <pre wrap="">This isn't the first time I've wondered exactly which signal was meant
in a postmaster child-crash report.  Seems like it might be worth
expending some code on a symbolic translation, instead of just printing
the number.  That'd be easy enough (for common signal names) on Unix,
but has anyone got a suggestion how we might do something useful on
Windows?
</pre>
    </blockquote>
    <br>
    Here's a typical Windows exception:<br>
    <br>
    <br>
    2012-10-04 14:29:08 CEST LOG:&nbsp; server process (PID 1416) was
    terminated by exception 0xC0000005<br>
    <br>
    2012-10-04 14:29:08 CEST HINT:&nbsp; See C include file "ntstatus.h" for
    a description of the hexadecimal value.<br>
    <br>
    <br>
    These codes can be translated with FormatMessage:
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <br>
    <br>
    &nbsp;
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a
href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms679351%28v=vs.85%29.aspx">http://msdn.microsoft.com/en-us/library/windows/desktop/ms679351(v=vs.85).aspx</a><br>
    &nbsp; <a href="http://support.microsoft.com/kb/259693">http://support.microsoft.com/kb/259693</a><br>
    <br>
    FormatMessage may not be safe to perform in the context of a munged
    heap or some other failure conditions, so you probably don't want to
    do it from a crash handler. It is safe for the postmaster to do it
    based on the exception code it gets from the dying backend, though.<br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <br>
    I'd say the best option is for the postmaster to print the
    FormatMessage(
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    FORMAT_MESSAGE_ALLOCATE_BUFFER|FORMAT_MESSAGE_FROM_SYSTEM|FORMAT_MESSAGE_FROM_HMODULE,
    ...) output when it sees the exception code from the dying backend.<br>
    <br>
    RtlNtStatusToDosError may also be of interest: <a
href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms680600%28v=vs.85%29.aspx">http://msdn.microsoft.com/en-us/library/windows/desktop/ms680600(v=vs.85).aspx</a>
    ... but it's in Winternl.h so it's not guaranteed to exist / be
    compatible between versions and can only be accessed via runtime
    dynamic linking. Not ideal.<br>
    <br>
    --<br>
    Craig Ringer<br>
  </body>
</html>

--------------000402020408050807040308--