DosError().
---
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
> Sent: Tuesday, January 23, 2007 7:35 AM
> To: Tom Lane
> Cc: Magnus Haga
Chuck McDevitt wrote:
Win32 exception codes start with a two-bit severity indication.
00 means "success", so nothing is wrong.
01 is an "informational" messages.
10 is a "warning" message.
11 is an "error".
That's why the common exception codes you see start with hex C0, as they
are "errors".
T
FormatMessage and it will work.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
Sent: Tuesday, January 23, 2007 7:35 AM
To: Tom Lane
Cc: Magnus Hagander; Takayuki Tsunakawa; PostgreSQL-patches; Alvaro
Herrera; ITAGAKI Takahiro
Subject: Re
I worked with Magnus and it seems pulling message text from ntdll.dll
doesn't work for all cases, so we are left just suggesting
/include/ntstatus.h, which is what we have now. Magnus concurs.
---
Magnus Hagander wrote:
> O
Magnus Hagander wrote:
> > The major place we use it is for backend termination checking, and we
> > know the return values there. The other place is for the return value
> > of pipe().
>
> I assume you mean popen()/pclose()? Because pipe() is implemented using
> sockets in our win32 ports layer.
On Tue, Jan 23, 2007 at 10:40:40AM -0500, Bruce Momjian wrote:
> >
> > Depends on what you mean with OS.
> > There are a *lot* of tools that will return exitcodes >0x100 that are
> > part of the OS. As a relevant example, Windows installer will return
> > exitcode 3010 means "needs to reboot but d
Magnus Hagander wrote:
> > This says you can get text for exceptions, but it didn't work for me,
> > but I didn't try loading ntdll.dll:
> >
> > http://support.microsoft.com/kb/259693
>
> Loading ntdll.dll lets you see Kernel mode API errors. If these are
> indeed the same as userspace except
Magnus Hagander wrote:
> On Tue, Jan 23, 2007 at 10:26:29AM -0500, Bruce Momjian wrote:
> > Magnus Hagander wrote:
> > > On Tue, Jan 23, 2007 at 10:11:58AM -0500, Bruce Momjian wrote:
> > > > Magnus Hagander wrote:
> > > > > > > I think that's incorrect information to the user :-(
> > > > > > > If
On Tue, Jan 23, 2007 at 10:32:58AM -0500, Bruce Momjian wrote:
> Takayuki Tsunakawa wrote:
> > From: "Magnus Hagander" <[EMAIL PROTECTED]>
> > > Are you entirely sure that ntstatus.h is where to look? Because per
> > > whatever docs I've found, that contains "device driver errors" and
> > *not*
> >
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Magnus Hagander wrote:
> >> Now, if we're only caring about exit() from *postgresqls own processes*,
> >> that might hold true. In which case I withdraw that objection as long as
> >> the comment i updated to reflect this ;-) But if we
On Tue, Jan 23, 2007 at 10:26:29AM -0500, Bruce Momjian wrote:
> Magnus Hagander wrote:
> > On Tue, Jan 23, 2007 at 10:11:58AM -0500, Bruce Momjian wrote:
> > > Magnus Hagander wrote:
> > > > > > I think that's incorrect information to the user :-(
> > > > > > If the child terminates with exit(1),
Takayuki Tsunakawa wrote:
> From: "Magnus Hagander" <[EMAIL PROTECTED]>
> > Are you entirely sure that ntstatus.h is where to look? Because per
> > whatever docs I've found, that contains "device driver errors" and
> *not*
> > exception codes.
>
> Yes, what you are pointing out is correct. winbas
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> Now, if we're only caring about exit() from *postgresqls own processes*,
>> that might hold true. In which case I withdraw that objection as long as
>> the comment i updated to reflect this ;-) But if we're talking about
>> exit(
Magnus Hagander wrote:
> On Tue, Jan 23, 2007 at 10:11:58AM -0500, Bruce Momjian wrote:
> > Magnus Hagander wrote:
> > > > > I think that's incorrect information to the user :-(
> > > > > If the child terminates with exit(1), we will then say "child process
> > > > > was terminated by exception 1.
On Tue, Jan 23, 2007 at 10:11:58AM -0500, Bruce Momjian wrote:
> Magnus Hagander wrote:
> > > > I think that's incorrect information to the user :-(
> > > > If the child terminates with exit(1), we will then say "child process
> > > > was terminated by exception 1. This seems to be a bug", which is
Magnus Hagander wrote:
> > > I think that's incorrect information to the user :-(
> > > If the child terminates with exit(1), we will then say "child process
> > > was terminated by exception 1. This seems to be a bug", which is clearly
> > > not true.
> > >
> > > Unless you know a sure way of det
On Tue, Jan 23, 2007 at 09:29:19AM -0500, Bruce Momjian wrote:
> Magnus Hagander wrote:
> > On Tue, Jan 23, 2007 at 06:50:06PM +0900, Takayuki Tsunakawa wrote:
> > > From: "Magnus Hagander" <[EMAIL PROTECTED]>
> > > > Are you entirely sure that ntstatus.h is where to look? Because per
> > > > whate
Magnus Hagander wrote:
> On Tue, Jan 23, 2007 at 06:50:06PM +0900, Takayuki Tsunakawa wrote:
> > From: "Magnus Hagander" <[EMAIL PROTECTED]>
> > > Are you entirely sure that ntstatus.h is where to look? Because per
> > > whatever docs I've found, that contains "device driver errors" and
> > *not*
>
On Tue, Jan 23, 2007 at 06:50:06PM +0900, Takayuki Tsunakawa wrote:
> From: "Magnus Hagander" <[EMAIL PROTECTED]>
> > Are you entirely sure that ntstatus.h is where to look? Because per
> > whatever docs I've found, that contains "device driver errors" and
> *not*
> > exception codes.
>
> Yes, wha
From: "Magnus Hagander" <[EMAIL PROTECTED]>
> Are you entirely sure that ntstatus.h is where to look? Because per
> whatever docs I've found, that contains "device driver errors" and
*not*
> exception codes.
Yes, what you are pointing out is correct. winbase.h and winnt.h
should be consulted inst
On Mon, Jan 22, 2007 at 10:35:11PM -0500, Bruce Momjian wrote:
> Takayuki Tsunakawa wrote:
> > From: "Bruce Momjian" <[EMAIL PROTECTED]>
> > > OK, I have tested on MinGW and found I can use FormatMessage() to
> > print
> > > a description for all ERROR* system() failures, rather than print a
> > he
Bruce Momjian wrote:
> Takayuki Tsunakawa wrote:
>> From: "Bruce Momjian" <[EMAIL PROTECTED]>
>> Yes, you are 100% correct that I had exceptions and errors confused.
>> I
>>> have backed out the patch that used FormatMessage(), and instead of
>>> using a URL, the message is now:
>>>
>>> child proc
Takayuki Tsunakawa wrote:
> From: "Bruce Momjian" <[EMAIL PROTECTED]>
> Yes, you are 100% correct that I had exceptions and errors confused.
> I
> > have backed out the patch that used FormatMessage(), and instead of
> > using a URL, the message is now:
> >
> > child process was terminated by exce
t;[EMAIL PROTECTED]>
To: "Takayuki Tsunakawa" <[EMAIL PROTECTED]>
Cc: "PostgreSQL-patches" ; "Tom Lane"
<[EMAIL PROTECTED]>; "Alvaro Herrera" <[EMAIL PROTECTED]>;
"Magnus Hagander" <[EMAIL PROTECTED]>; "ITAGAKI Takahiro&
Takayuki Tsunakawa wrote:
> From: "Bruce Momjian" <[EMAIL PROTECTED]>
> > OK, I have tested on MinGW and found I can use FormatMessage() to
> print
> > a description for all ERROR* system() failures, rather than print a
> hex
> > value. This removes the need for a URL or lookup of hex values.
> >
From: "Bruce Momjian" <[EMAIL PROTECTED]>
> OK, I have tested on MinGW and found I can use FormatMessage() to
print
> a description for all ERROR* system() failures, rather than print a
hex
> value. This removes the need for a URL or lookup of hex values.
> Attached and applied.
Excuse me if I'm
;; "Magnus Hagander" <[EMAIL PROTECTED]>;
"ITAGAKI Takahiro" <[EMAIL PROTECTED]>;
"PostgreSQL-patches"
Sent: Tuesday, January 23, 2007 10:37 AM
Subject: Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
> Takayuki Tsunakawa wrote:
>> From:
OK, I have tested on MinGW and found I can use FormatMessage() to print
a description for all ERROR* system() failures, rather than print a hex
value. This removes the need for a URL or lookup of hex values.
Attached and applied.
-
Takayuki Tsunakawa wrote:
> From: "Bruce Momjian" <[EMAIL PROTECTED]>
> > Tom Lane wrote:
> >> Basically this whole idea is misconceived. Just print the number
> and
> >> have done.
> >
> > And how do people interpret that number?
>
> I understand that "people" Bruce-san is saying means PostgreSQ
From: "Bruce Momjian" <[EMAIL PROTECTED]>
> Tom Lane wrote:
>> Basically this whole idea is misconceived. Just print the number
and
>> have done.
>
> And how do people interpret that number?
I understand that "people" Bruce-san is saying means PostgreSQL
developers, not ordinary users.
When ordin
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> OK, maybe /doc or src/tools. A more radical approach would be to put
> >> the list in our documentation, or have initdb install it.
>
> > Why not put it in techdocs or some such?
>
> I think we've learned
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> OK, maybe /doc or src/tools. A more radical approach would be to put
>> the list in our documentation, or have initdb install it.
> Why not put it in techdocs or some such?
I think we've learned by now that putting copies of ot
Bruce Momjian wrote:
> Magnus Hagander wrote:
> > Bruce Momjian wrote:
> > >
> > > Agreed. I propose we put the file in src/tools/msvc and link to our CVS
> > > source tree or something.
> > >
> > Uh, AFAIK they're not MSVC specific, but also apply to mingw.
> > src/tools/msvc is msvc only - if
Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>> FYI, here are the URL's I mention in our source code:
> >>> * Wine (URL used in our error messages) -
> >>> * http://source.winehq.org/source/include/ntstatus.h
> >
Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> FYI, here are the URL's I mention in our source code:
>>> * Wine (URL used in our error messages) -
>>> * http://source.winehq.org/source/include/ntstatus.h
>>> * Descriptions -
>>> http:/
Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Magnus Hagander wrote:
> > Even if it were the responsibility of the error message to suggest this,
> > a URL seems far too transient.
> I agree; more so given that the URL points to the Wine project pages.
> And it's not user docu
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > FYI, here are the URL's I mention in our source code:
>
> > * Wine (URL used in our error messages) -
> > * http://source.winehq.org/source/include/ntstatus.h
> > * Descriptions -
> > http://www.comp.nus.edu.sg/
Bruce Momjian wrote:
> Magnus Hagander wrote:
> Even if it were the responsibility of the error message to suggest this,
> a URL seems far too transient.
I agree; more so given that the URL points to the Wine project pages.
And it's not user documentation, but source code, which m
Magnus Hagander wrote:
> >>> Even if it were the responsibility of the error message to suggest this,
> >>> a URL seems far too transient.
> >> I agree; more so given that the URL points to the Wine project pages.
> >> And it's not user documentation, but source code, which makes it less
> >> appro
Bruce Momjian <[EMAIL PROTECTED]> writes:
> FYI, here are the URL's I mention in our source code:
> * Wine (URL used in our error messages) -
> * http://source.winehq.org/source/include/ntstatus.h
> * Descriptions -
> http://www.comp.nus.edu.sg/~wuyongzh/my_doc/ntstatus.txt
>>> Even if it were the responsibility of the error message to suggest this,
>>> a URL seems far too transient.
>> I agree; more so given that the URL points to the Wine project pages.
>> And it's not user documentation, but source code, which makes it less
>> appropriate.
>
> OK, so what suggesti
bruce wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> It should not be there at all. Do you see URLs in any of our other
> > >> error messages?
> >
> > > Sure, ideally, but how else can we give information about that hex
> > > value?
> >
> > It
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> It should not be there at all. Do you see URLs in any of our other
> > >> error messages?
> >
> > > Sure, ideally, but how else can we give information about that hex
> > > value?
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> It should not be there at all. Do you see URLs in any of our other
> >> error messages?
>
> > Sure, ideally, but how else can we give information about that hex
> > value?
>
> It's not the responsibility of that
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It should not be there at all. Do you see URLs in any of our other
>> error messages?
> Sure, ideally, but how else can we give information about that hex
> value?
It's not the responsibility of that error message to tell someone to
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> I have applied a modified version of this patch. We now print the
> >> exception value in hex, and give a URL where the exception can be looked
> >> up.
>
> > Humm, wouldn't it be more appropriate to put th
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> I have applied a modified version of this patch. We now print the
>> exception value in hex, and give a URL where the exception can be looked
>> up.
> Humm, wouldn't it be more appropriate to put the URL in a errhint()
> instead
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > I have applied a modified version of this patch. We now print the
> > exception value in hex, and give a URL where the exception can be looked
> > up.
>
> Humm, wouldn't it be more appropriate to put the URL in a errhint()
> instead?
>
> > +
Bruce Momjian wrote:
>
> I have applied a modified version of this patch. We now print the
> exception value in hex, and give a URL where the exception can be looked
> up.
Humm, wouldn't it be more appropriate to put the URL in a errhint()
instead?
> + ereport(lev,
> +
> +
I have applied a modified version of this patch. We now print the
exception value in hex, and give a URL where the exception can be looked
up.
---
Bruce Momjian wrote:
>
> I did some research on this, and found a nice Win3
I did some research on this, and found a nice Win32 list of STATUS_
error values. Looking at the list, I think the non-exit() return values
are much larger than just the second high bit.
I am proposing the attached patch, which basically has all system()
return values < 0x100 as exit() calls, an
51 matches
Mail list logo
