Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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". > > The rest of the top 16 bits are the "facility" that caused the error. > Often not filled in. > > To Convert an NT exception code (ntstatus) to a Win32 error code, you > call this routine: > > ULONG RtlNtStatusToDosError( > NTSTATUS Status > ); > > > Then you can pass it to FormatMessage and it will work. I looked on MinGW and it seems it doesn't support RtlNtStatusToDosError(), so I just added a comment that some day we might want to use it: * Some day we might want to print descriptions for the most common * exceptions, rather than printing an include file name. We could use * RtlNtStatusToDosError() and pass to FormatMessage(), which can print * the text of error values, but MinGW does not support * RtlNtStatusToDosError(). --- > > > -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: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too > > 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're talking > about > > >> exit() in general of any process, then it's simply wrong. > > > > > Right, that code is only used by the backend and tools. > > > > We can reasonably assume that no Postgres code will exit() with a > value > > bigger than 255, because to do so would be unportable. > > > > I'm more concerned about the other direction: can we be sure that a > > status value less than 255 is from exit() rather than something that > > should be called an exception? > > > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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". The rest of the top 16 bits are the "facility" that caused the error. Often not filled in. Almost, AAUI. The next significant bit after the severity bits is a custom flag - 0 indicates it is a MS exception, 1 that it's from a third party. The remaining upper 13 bits are the facility. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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". The rest of the top 16 bits are the "facility" that caused the error. Often not filled in. To Convert an NT exception code (ntstatus) to a Win32 error code, you call this routine: ULONG RtlNtStatusToDosError( NTSTATUS Status ); Then you can pass it to 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: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too 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're talking about > >> exit() in general of any process, then it's simply wrong. > > > Right, that code is only used by the backend and tools. > > We can reasonably assume that no Postgres code will exit() with a value > bigger than 255, because to do so would be unportable. > > I'm more concerned about the other direction: can we be sure that a > status value less than 255 is from exit() rather than something that > should be called an exception? ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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: > 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 didn't reboot". MSI is a part > > > of the OS, but it's not kernel... Same thing for things like the service > > > control manager (trying to operate on a service that has been removed > > > gives you error 1060). > > > > Is there a portable way to get the _exception_ value from system(), > > rather than the error code? We could go with just > 0xC000 values > > as exceptions. (This is clearly showing the mess that is the WIN32 > > API.) > > AFAIK, the way to do that is to use SEH. But this is not supported by > MingW. > > > > > > would break that assumption. (And yes, it works) > > > > > exit() takes a 32-bit signed integer, and that's what comes out to the > > > > > calling program (verified both with console and standalone program) > > > > > > > > > > The MSDN link referes to the DDK which has to do with driver > > > > > development, not userspace. AFAIK, that list is not relevant here, and > > > > > I've seen no actual reference so far that it should be used to look up > > > > > exit codes. > > > > > > > > > > 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() in general of any process, then it's simply wrong. > > > > > > > > Right, that code is only used by the backend and tools. > > > > > > We should be very clear about that in our comment then, and the current > > > comment is not. And the part referring to the DDK should just be > > > removed, because it's simply incorrect. > > > > > > For example, don't we call cmd for PITR scripts? If we're using any of > > > these macros on the return value from there we are *NOT* certain of what > > > it will be, and then need to document that as a requirement on those > > > scripts. > > > > 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. > > //Magnus -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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. Yes, popen/pclose. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 didn't reboot". MSI is a part > > of the OS, but it's not kernel... Same thing for things like the service > > control manager (trying to operate on a service that has been removed > > gives you error 1060). > > Is there a portable way to get the _exception_ value from system(), > rather than the error code? We could go with just > 0xC000 values > as exceptions. (This is clearly showing the mess that is the WIN32 > API.) AFAIK, the way to do that is to use SEH. But this is not supported by MingW. > > > > would break that assumption. (And yes, it works) > > > > exit() takes a 32-bit signed integer, and that's what comes out to the > > > > calling program (verified both with console and standalone program) > > > > > > > > The MSDN link referes to the DDK which has to do with driver > > > > development, not userspace. AFAIK, that list is not relevant here, and > > > > I've seen no actual reference so far that it should be used to look up > > > > exit codes. > > > > > > > > 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() in general of any process, then it's simply wrong. > > > > > > Right, that code is only used by the backend and tools. > > > > We should be very clear about that in our comment then, and the current > > comment is not. And the part referring to the DDK should just be > > removed, because it's simply incorrect. > > > > For example, don't we call cmd for PITR scripts? If we're using any of > > these macros on the return value from there we are *NOT* certain of what > > it will be, and then need to document that as a requirement on those > > scripts. > > 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. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 exceptions, then you can load ntdll to get > those. If you don't load ntdll, you can only look at "normal errors". OK, interesting. Let me test in that direction. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 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 determining if the exitcode is a
> > > > > > > normal
> > > > > > > exitcode or an exception code.
> > > > > >
> > > > > > Current CVS believes values >= 0x100 are non-exit() terminations.
> > > > >
> > > > > Why does it do that :-) That's clearly wrong. There are plenty of
> > > > > exitcodes > 0x100 that aren't exceptions.
> > > >
> > > > Please read include/port/win32.h comment section on this and then reply.
> > > > We only care about non-exit() exits.
> > >
> > > Right. I did. and exit() can return a lot of error codes > 0x100. For
> > > example,
> > > a simple:
> > > int main(int argc, char *argv) {
> > >exit(12345);
> > > }
> >
> > Yes, I know it works, but it can return 0xc005 too. I think we have
> > to be reasonable and say >= 0x100 is probably the OS.
>
> 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 didn't reboot". MSI is a part
> of the OS, but it's not kernel... Same thing for things like the service
> control manager (trying to operate on a service that has been removed
> gives you error 1060).
Is there a portable way to get the _exception_ value from system(),
rather than the error code? We could go with just > 0xC000 values
as exceptions. (This is clearly showing the mess that is the WIN32
API.)
> > > would break that assumption. (And yes, it works)
> > > exit() takes a 32-bit signed integer, and that's what comes out to the
> > > calling program (verified both with console and standalone program)
> > >
> > > The MSDN link referes to the DDK which has to do with driver
> > > development, not userspace. AFAIK, that list is not relevant here, and
> > > I've seen no actual reference so far that it should be used to look up
> > > exit codes.
> > >
> > > 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() in general of any process, then it's simply wrong.
> >
> > Right, that code is only used by the backend and tools.
>
> We should be very clear about that in our comment then, and the current
> comment is not. And the part referring to the DDK should just be
> removed, because it's simply incorrect.
>
> For example, don't we call cmd for PITR scripts? If we're using any of
> these macros on the return value from there we are *NOT* certain of what
> it will be, and then need to document that as a requirement on those
> scripts.
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().
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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* > > > exception codes. > > > > Yes, what you are pointing out is correct. winbase.h and winnt.h > > should be consulted instead of ntstatus.h. See the the section > > "Return Value" in the following page: > > > > http://msdn2.microsoft.com/ru-ru/library/ms679356.aspx > > Well, it seems to be in two place. I see at: > > http://www.microsoft.com/msj/0197/exception/exception.aspx > > The ExceptionCode parameter is the number that the operating system > assigned to the exception. You can see a list of various exception codes > in WINNT.H by searching for #defines that start with "STATUS_". For > example, the code for the all-too-familiar STATUS_ACCESS_VIOLATION is > 0xC005. A more complete set of exception codes can be found in > NTSTATUS.H from the Windows NT DDK. Actually, that's the first reference so far to say that a kernel level error code is the same as a userspace exception code. If it is, then it's safe to use as such. MSJ is generall a very good reference for these things, even though it's nto an actual documentation. > > Furthermore, the message is meaningless for users because they can do > > nothing with the information. So, I think the message should say > > something like > > > > child process was terminated by exception %X > > This seems to be a bug of PostgreSQL. > > Please report this message with the details of the phynomenon to > > PostgreSQL developers. > > I am hoping some of the hex values will have descriptions that will help > users solve problems in their operating system configuration, rather > than asking us. If they are in a crisis, asking the community might > not be quick enough. > > FYI, here is a patch that recommends ntstatus.h: > > http://blog.opsan.com/archive/2005/05/05/447.aspx > http://www.osronline.com/article.cfm?article=207 This second one is referring to DDK again. The first one doesn't refer to what it's looking up at all :-( > 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 exceptions, then you can load ntdll to get those. If you don't load ntdll, you can only look at "normal errors". //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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're talking about > >> exit() in general of any process, then it's simply wrong. > > > Right, that code is only used by the backend and tools. > > We can reasonably assume that no Postgres code will exit() with a value > bigger than 255, because to do so would be unportable. > > I'm more concerned about the other direction: can we be sure that a > status value less than 255 is from exit() rather than something that > should be called an exception? Here are the values listed in ntstatus.h < 0x100: 36 #define STATUS_WAIT_0((NTSTATUS) 0x) 37 #define STATUS_WAIT_1((NTSTATUS) 0x0001) 38 #define STATUS_WAIT_2((NTSTATUS) 0x0002) 39 #define STATUS_WAIT_3((NTSTATUS) 0x0003) 40 #define STATUS_WAIT_63 ((NTSTATUS) 0x003f) 41 #define STATUS_ABANDONED ((NTSTATUS) 0x0080) 42 #define STATUS_ABANDONED_WAIT_0 ((NTSTATUS) 0x0080) 43 #define STATUS_ABANDONED_WAIT_63 ((NTSTATUS) 0x00BF) 44 #define STATUS_USER_APC ((NTSTATUS) 0x00C0) > And to get back to the point, surely all this confusion proves the point > about how the error message should NOT try to tell people how to > interpret the number. This all started because we as a community couldn't interpret the number. I don't see how pushing the interpetation to users helps us. We need to nail this down. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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), 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 determining if the exitcode is a
> > > > > > normal
> > > > > > exitcode or an exception code.
> > > > >
> > > > > Current CVS believes values >= 0x100 are non-exit() terminations.
> > > >
> > > > Why does it do that :-) That's clearly wrong. There are plenty of
> > > > exitcodes > 0x100 that aren't exceptions.
> > >
> > > Please read include/port/win32.h comment section on this and then reply.
> > > We only care about non-exit() exits.
> >
> > Right. I did. and exit() can return a lot of error codes > 0x100. For
> > example,
> > a simple:
> > int main(int argc, char *argv) {
> >exit(12345);
> > }
>
> Yes, I know it works, but it can return 0xc005 too. I think we have
> to be reasonable and say >= 0x100 is probably the OS.
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 didn't reboot". MSI is a part
of the OS, but it's not kernel... Same thing for things like the service
control manager (trying to operate on a service that has been removed
gives you error 1060).
> > would break that assumption. (And yes, it works)
> > exit() takes a 32-bit signed integer, and that's what comes out to the
> > calling program (verified both with console and standalone program)
> >
> > The MSDN link referes to the DDK which has to do with driver
> > development, not userspace. AFAIK, that list is not relevant here, and
> > I've seen no actual reference so far that it should be used to look up
> > exit codes.
> >
> > 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() in general of any process, then it's simply wrong.
>
> Right, that code is only used by the backend and tools.
We should be very clear about that in our comment then, and the current
comment is not. And the part referring to the DDK should just be
removed, because it's simply incorrect.
For example, don't we call cmd for PITR scripts? If we're using any of
these macros on the return value from there we are *NOT* certain of what
it will be, and then need to document that as a requirement on those
scripts.
//Magnus
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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. winbase.h and winnt.h > should be consulted instead of ntstatus.h. See the the section > "Return Value" in the following page: > > http://msdn2.microsoft.com/ru-ru/library/ms679356.aspx Well, it seems to be in two place. I see at: http://www.microsoft.com/msj/0197/exception/exception.aspx The ExceptionCode parameter is the number that the operating system assigned to the exception. You can see a list of various exception codes in WINNT.H by searching for #defines that start with "STATUS_". For example, the code for the all-too-familiar STATUS_ACCESS_VIOLATION is 0xC005. A more complete set of exception codes can be found in NTSTATUS.H from the Windows NT DDK. And it seems Wine also has it in both places. The nice thing about ntstatus.h is that it _only_ contains exception values, rather than winnt.h, which has lots of other stuff too. > Furthermore, the message is meaningless for users because they can do > nothing with the information. So, I think the message should say > something like > > child process was terminated by exception %X > This seems to be a bug of PostgreSQL. > Please report this message with the details of the phynomenon to > PostgreSQL developers. I am hoping some of the hex values will have descriptions that will help users solve problems in their operating system configuration, rather than asking us. If they are in a crisis, asking the community might not be quick enough. FYI, here is a patch that recommends ntstatus.h: http://blog.opsan.com/archive/2005/05/05/447.aspx http://www.osronline.com/article.cfm?article=207 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 -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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() in general of any process, then it's simply wrong. > Right, that code is only used by the backend and tools. We can reasonably assume that no Postgres code will exit() with a value bigger than 255, because to do so would be unportable. I'm more concerned about the other direction: can we be sure that a status value less than 255 is from exit() rather than something that should be called an exception? And to get back to the point, surely all this confusion proves the point about how the error message should NOT try to tell people how to interpret the number. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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. This seems to be a bug", which is
> > > > > clearly
> > > > > not true.
> > > > >
> > > > > Unless you know a sure way of determining if the exitcode is a normal
> > > > > exitcode or an exception code.
> > > >
> > > > Current CVS believes values >= 0x100 are non-exit() terminations.
> > >
> > > Why does it do that :-) That's clearly wrong. There are plenty of
> > > exitcodes > 0x100 that aren't exceptions.
> >
> > Please read include/port/win32.h comment section on this and then reply.
> > We only care about non-exit() exits.
>
> Right. I did. and exit() can return a lot of error codes > 0x100. For
> example,
> a simple:
> int main(int argc, char *argv) {
>exit(12345);
> }
Yes, I know it works, but it can return 0xc005 too. I think we have
to be reasonable and say >= 0x100 is probably the OS.
> would break that assumption. (And yes, it works)
> exit() takes a 32-bit signed integer, and that's what comes out to the
> calling program (verified both with console and standalone program)
>
> The MSDN link referes to the DDK which has to do with driver
> development, not userspace. AFAIK, that list is not relevant here, and
> I've seen no actual reference so far that it should be used to look up
> exit codes.
>
> 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() in general of any process, then it's simply wrong.
Right, that code is only used by the backend and tools.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 clearly
> > > > not true.
> > > >
> > > > Unless you know a sure way of determining if the exitcode is a normal
> > > > exitcode or an exception code.
> > >
> > > Current CVS believes values >= 0x100 are non-exit() terminations.
> >
> > Why does it do that :-) That's clearly wrong. There are plenty of
> > exitcodes > 0x100 that aren't exceptions.
>
> Please read include/port/win32.h comment section on this and then reply.
> We only care about non-exit() exits.
Right. I did. and exit() can return a lot of error codes > 0x100. For example,
a simple:
int main(int argc, char *argv) {
exit(12345);
}
would break that assumption. (And yes, it works)
exit() takes a 32-bit signed integer, and that's what comes out to the
calling program (verified both with console and standalone program)
The MSDN link referes to the DDK which has to do with driver
development, not userspace. AFAIK, that list is not relevant here, and
I've seen no actual reference so far that it should be used to look up
exit codes.
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() in general of any process, then it's simply wrong.
//Magnus
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 determining if the exitcode is a normal > > > exitcode or an exception code. > > > > Current CVS believes values >= 0x100 are non-exit() terminations. > > Why does it do that :-) That's clearly wrong. There are plenty of > exitcodes > 0x100 that aren't exceptions. Please read include/port/win32.h comment section on this and then reply. We only care about non-exit() exits. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 > > > > 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 instead of ntstatus.h. See the the section > > > "Return Value" in the following page: > > > > > > http://msdn2.microsoft.com/ru-ru/library/ms679356.aspx > > > > > > Furthermore, the message is meaningless for users because they can do > > > nothing with the information. So, I think the message should say > > > something like > > > > > > child process was terminated by exception %X > > > This seems to be a bug of PostgreSQL. > > > Please report this message with the details of the phynomenon to > > > PostgreSQL developers. > > > > > > > > > What do you think? > > > > 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 determining if the exitcode is a normal > > exitcode or an exception code. > > Current CVS believes values >= 0x100 are non-exit() terminations. Why does it do that :-) That's clearly wrong. There are plenty of exitcodes > 0x100 that aren't exceptions. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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* > > > exception codes. > > > > Yes, what you are pointing out is correct. winbase.h and winnt.h > > should be consulted instead of ntstatus.h. See the the section > > "Return Value" in the following page: > > > > http://msdn2.microsoft.com/ru-ru/library/ms679356.aspx > > > > Furthermore, the message is meaningless for users because they can do > > nothing with the information. So, I think the message should say > > something like > > > > child process was terminated by exception %X > > This seems to be a bug of PostgreSQL. > > Please report this message with the details of the phynomenon to > > PostgreSQL developers. > > > > > > What do you think? > > 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 determining if the exitcode is a normal > exitcode or an exception code. Current CVS believes values >= 0x100 are non-exit() terminations. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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, what you are pointing out is correct. winbase.h and winnt.h > should be consulted instead of ntstatus.h. See the the section > "Return Value" in the following page: > > http://msdn2.microsoft.com/ru-ru/library/ms679356.aspx > > Furthermore, the message is meaningless for users because they can do > nothing with the information. So, I think the message should say > something like > > child process was terminated by exception %X > This seems to be a bug of PostgreSQL. > Please report this message with the details of the phynomenon to > PostgreSQL developers. > > > What do you think? 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 determining if the exitcode is a normal exitcode or an exception code. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 instead of ntstatus.h. See the the section "Return Value" in the following page: http://msdn2.microsoft.com/ru-ru/library/ms679356.aspx Furthermore, the message is meaningless for users because they can do nothing with the information. So, I think the message should say something like child process was terminated by exception %X This seems to be a bug of PostgreSQL. Please report this message with the details of the phynomenon to PostgreSQL developers. What do you think? ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 > > hex > > > value. This removes the need for a URL or lookup of hex values. > > > Attached and applied. > > > > Excuse me if I'm misunderstanding, but I'm afraid you are mixing up > > Win32 error codes and exception codes. I saw the following fragment > > in your patch: > > > > ! * On MinGW, system() returns STATUS_* values. MSVC might be > > ! * different. To test, create a binary that does *(NULL), and > > ! * then create a second binary that calls it via system(), > > ! * and check the return value of system(). On MinGW, it is > > ! * 0xC005 == STATUS_ACCESS_VIOLATION, and 0x5 is a value > > ! * FormatMessage() can look up. GetLastError() does not work; > > ! * always zero. > > > > Exception codes and error codes are different and not related. In the > > above test, 0xC005 is an "exception code". On the other hand, what > > FormatMessage() accepts is an error code. Error codes can't derived > > from exception codes. Stripping off 0xC bit from an exception code > > does not convert it to an error code. > > I suspect the reason why you misunderstood is that the descriptions > > are similar: > > the description for exception 0xC005 (STATUS_ACCESS_VIOLATION) is > > "access violation" (though the text can't be obtained). This is > > caused by an illegal memory access. This is a program bug. > > The description for 0x5 (ERROR_ACCESS_DENIED) is "Access is denied." > > This is caused by permission checks. This is not a bug, and can > > happen normally. > > > > Try "1.0 / 0.0" (devide by zero) instead of (*NULL). What would your > > patch display? The exception would be 0xC08E > > (STATUS_FLOAT_DIVIDE_BY_ZERO), I think. 0x8E is ERROR_BUSY_DRIVE. > > 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 exception %X > See /include/ntstatus.h for a description of the hex value. > > When I search for /include/ntstatus.h, I get the Wine page first, so > hopefully we can mark this item as completed. 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. If it really is, then using FormatMessage is correct - because it's not an exception value, it'sa DDK error value. AFAIK, that's not the same as an exception. (Though you have to add the search of ntdll.dll, of course) //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 process was terminated by exception %X >>> See /include/ntstatus.h for a description of the hex value. >>> >>> When I search for /include/ntstatus.h, I get the Wine page first, so >>> hopefully we can mark this item as completed. >> Thank you, Bruce-san. I agree. > > The Win32 port has always been done in small steps, sometimes to the > left or right, but eventually forward. He feints to the left, he feints to the right, he ducks and POW! -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 exception %X > > See /include/ntstatus.h for a description of the hex value. > > > > When I search for /include/ntstatus.h, I get the Wine page first, so > > hopefully we can mark this item as completed. > > Thank you, Bruce-san. I agree. The Win32 port has always been done in small steps, sometimes to the left or right, but eventually forward. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 exception %X > See /include/ntstatus.h for a description of the hex value. > > When I search for /include/ntstatus.h, I get the Wine page first, so > hopefully we can mark this item as completed. Thank you, Bruce-san. I agree. - Original Message - From: "Bruce Momjian" <[EMAIL PROTECTED]> To: "Takayuki Tsunakawa" <[EMAIL PROTECTED]> Cc: "PostgreSQL-patches" ; "Tom Lane" <[EMAIL PROTECTED]>; "Alvaro Herrera" <[EMAIL PROTECTED]>; "Magnus Hagander" <[EMAIL PROTECTED]>; "ITAGAKI Takahiro" <[EMAIL PROTECTED]> Sent: Tuesday, January 23, 2007 12:35 PM Subject: Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too > 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. >> > Attached and applied. >> >> Excuse me if I'm misunderstanding, but I'm afraid you are mixing up >> Win32 error codes and exception codes. I saw the following fragment >> in your patch: >> >> ! * On MinGW, system() returns STATUS_* values. MSVC might be >> ! * different. To test, create a binary that does *(NULL), and >> ! * then create a second binary that calls it via system(), >> ! * and check the return value of system(). On MinGW, it is >> ! * 0xC005 == STATUS_ACCESS_VIOLATION, and 0x5 is a value >> ! * FormatMessage() can look up. GetLastError() does not work; >> ! * always zero. >> >> Exception codes and error codes are different and not related. In the >> above test, 0xC005 is an "exception code". On the other hand, what >> FormatMessage() accepts is an error code. Error codes can't derived >> from exception codes. Stripping off 0xC bit from an exception code >> does not convert it to an error code. >> I suspect the reason why you misunderstood is that the descriptions >> are similar: >> the description for exception 0xC005 (STATUS_ACCESS_VIOLATION) is >> "access violation" (though the text can't be obtained). This is >> caused by an illegal memory access. This is a program bug. >> The description for 0x5 (ERROR_ACCESS_DENIED) is "Access is denied." >> This is caused by permission checks. This is not a bug, and can >> happen normally. >> >> Try "1.0 / 0.0" (devide by zero) instead of (*NULL). What would your >> patch display? The exception would be 0xC08E >> (STATUS_FLOAT_DIVIDE_BY_ZERO), I think. 0x8E is ERROR_BUSY_DRIVE. > > 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 exception %X > See /include/ntstatus.h for a description of the hex value. > > When I search for /include/ntstatus.h, I get the Wine page first, so > hopefully we can mark this item as completed. > > -- > Bruce Momjian [EMAIL PROTECTED] > EnterpriseDBhttp://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org > ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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. > > Attached and applied. > > Excuse me if I'm misunderstanding, but I'm afraid you are mixing up > Win32 error codes and exception codes. I saw the following fragment > in your patch: > > ! * On MinGW, system() returns STATUS_* values. MSVC might be > ! * different. To test, create a binary that does *(NULL), and > ! * then create a second binary that calls it via system(), > ! * and check the return value of system(). On MinGW, it is > ! * 0xC005 == STATUS_ACCESS_VIOLATION, and 0x5 is a value > ! * FormatMessage() can look up. GetLastError() does not work; > ! * always zero. > > Exception codes and error codes are different and not related. In the > above test, 0xC005 is an "exception code". On the other hand, what > FormatMessage() accepts is an error code. Error codes can't derived > from exception codes. Stripping off 0xC bit from an exception code > does not convert it to an error code. > I suspect the reason why you misunderstood is that the descriptions > are similar: > the description for exception 0xC005 (STATUS_ACCESS_VIOLATION) is > "access violation" (though the text can't be obtained). This is > caused by an illegal memory access. This is a program bug. > The description for 0x5 (ERROR_ACCESS_DENIED) is "Access is denied." > This is caused by permission checks. This is not a bug, and can > happen normally. > > Try "1.0 / 0.0" (devide by zero) instead of (*NULL). What would your > patch display? The exception would be 0xC08E > (STATUS_FLOAT_DIVIDE_BY_ZERO), I think. 0x8E is ERROR_BUSY_DRIVE. 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 exception %X See /include/ntstatus.h for a description of the hex value. When I search for /include/ntstatus.h, I get the Wine page first, so hopefully we can mark this item as completed. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 misunderstanding, but I'm afraid you are mixing up Win32 error codes and exception codes. I saw the following fragment in your patch: ! * On MinGW, system() returns STATUS_* values. MSVC might be ! * different. To test, create a binary that does *(NULL), and ! * then create a second binary that calls it via system(), ! * and check the return value of system(). On MinGW, it is ! * 0xC005 == STATUS_ACCESS_VIOLATION, and 0x5 is a value ! * FormatMessage() can look up. GetLastError() does not work; ! * always zero. Exception codes and error codes are different and not related. In the above test, 0xC005 is an "exception code". On the other hand, what FormatMessage() accepts is an error code. Error codes can't derived from exception codes. Stripping off 0xC bit from an exception code does not convert it to an error code. I suspect the reason why you misunderstood is that the descriptions are similar: the description for exception 0xC005 (STATUS_ACCESS_VIOLATION) is "access violation" (though the text can't be obtained). This is caused by an illegal memory access. This is a program bug. The description for 0x5 (ERROR_ACCESS_DENIED) is "Access is denied." This is caused by permission checks. This is not a bug, and can happen normally. Try "1.0 / 0.0" (devide by zero) instead of (*NULL). What would your patch display? The exception would be 0xC08E (STATUS_FLOAT_DIVIDE_BY_ZERO), I think. 0x8E is ERROR_BUSY_DRIVE. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
> Well, I am thinking of cases where we the error can help the user > diagnose the problem. I have found a way to print descriptions with > FormatMessage(), and the codes without descriptions will just print as > hex. I also think this is correct. Like errno and strerror() combination on UNIX, descriptions obtained from FormatMessage() should be displayed with error codes from GetLastError(). I thought Bruce-san is trying to display descriptions (or a URL to them) for the "exception" codes, not "error" codes. Descriptions for exception codes can't be obtained with FormatMessage, can they? - Original Message - From: "Bruce Momjian" <[EMAIL PROTECTED]> To: "Takayuki Tsunakawa" <[EMAIL PROTECTED]> Cc: "Tom Lane" <[EMAIL PROTECTED]>; "Alvaro Herrera" <[EMAIL PROTECTED]>; "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: "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 ordinary users encounter an Win32 exception, what they can do is >> to report the message and the description of phenomenon to PostgreSQL >> developers. What can they do when they see the descriptive text of an >> exception code, such as "Access violation" for 0xC005? An >> exception means a bug of PostgreSQL. Win32 exceptions are different >> from errno on UNIX (counterpart of which is Win32 error code.) Can >> they avoid the exception by changing PostgreSQL settings? If luckly >> so in one case, can they think of the treatment from the message? >> >> If "people" means PostgreSQL developers, the descriptive text is not >> necessary either. I think the developers who try to solve the bug >> know where to refer to interpret the exception code. >> >> My opinion is the same as Tom-san's. > > Well, I am thinking of cases where we the error can help the user > diagnose the problem. I have found a way to print descriptions with > FormatMessage(), and the codes without descriptions will just print as > hex. > > -- > Bruce Momjian [EMAIL PROTECTED] > EnterpriseDBhttp://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend > ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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.
---
Bruce Momjian wrote:
> bruce wrote:
> > 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 by now that putting copies of other peoples' code
> > > in our tree isn't such a hot idea; what is going to cause it to be
> > > updated when things change? How do you know the values are even the
> > > same across all the Windows versions we support?
> > >
> > > Basically this whole idea is misconceived. Just print the number and
> > > have done.
> >
> > And how do people interpret that number?
>
> Ah, I found something:
>
> http://support.microsoft.com/kb/259693
>
> Someone on IRC says that is kernel mode only, and is looking for a
> user-mode version, so we would be able to print out a meaningful message
> rather than a hex value that has to be looked up.
>
> --
> Bruce Momjian [EMAIL PROTECTED]
> EnterpriseDBhttp://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
> ---(end of broadcast)---
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>choose an index scan if your joining column's datatypes do not
>match
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/postmaster/postmaster.c
===
RCS file: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.510
diff -c -c -r1.510 postmaster.c
*** src/backend/postmaster/postmaster.c 22 Jan 2007 19:38:05 - 1.510
--- src/backend/postmaster/postmaster.c 23 Jan 2007 01:43:22 -
***
*** 2430,2443
(errmsg("%s (PID %d) was terminated by signal %d",
procname, pid, WTERMSIG(exitstatus;
#else
! ereport(lev,
/*--
translator: %s is a noun phrase describing a child process, such as
"server process" */
! (errmsg("%s (PID %d) was terminated by exception %X",
! procname, pid, WTERMSIG(exitstatus)),
! errhint("See http://source.winehq.org/source/include/ntstatus.h for a description of the hex value.")));
#endif
else
ereport(lev,
--- 2430,2459
(errmsg("%s (PID %d) was terminated by signal %d",
procname, pid, WTERMSIG(exitstatus;
#else
! {
! static char last_system_error[512];
!
! if (WERRORCODE(exitstatus) == 0 ||
! FormatMessage(FORMAT_MESSAGE_IGNORE_INSERTS |
! FORMAT_MESSAGE_FROM_SYSTEM,
! NULL,
! WERRORCODE(exitstatus),
! MAKELANGID(LANG_ENGLISH, SUBLANG_DEFAULT),
! last_system_error,
! sizeof(last_system_error) - 1,
! NULL) == 0)
! snprintf(last_system_error, sizeof(last_system_error) - 1,
! "Unknown error %X.", WEXITSTATUS(exitstatus));
+ ereport(lev,
+
/*--
translator: %s is a noun phrase describing a child process, such as
"server process" */
! (errmsg("%s (PID %d) was terminated by the operating system",
! procname, pid),
! errdetail("%s", last_system_error)));
! }
#endif
else
ereport(lev,
Index: src/include/port/win32.h
===
RCS file: /cvsroot/pgsql/src/include/port/win32.h,v
retrieving revision 1.67
diff -c -c -r1.67 win32.h
*** src/include/port/win32.h 22 Jan 2007 18:32:57 - 1.67
--- src/include/port/win32.h 23 Jan 2007 01:43:23 -
***
*** 140,152
* Descriptions - http://www.comp.nus.edu.sg/~wuyongzh/my_doc/ntstatus.txt
* MS SDK - http://www.nologs.com/ntstatus.html
*
! * Some day we might want to print descriptions for the most common
! * exceptions, rather than printing a URL.
! */
! #define WIFEXITED(w)(((w) & 0XFF00) == 0)
! #define WIFSIGNALED(w) (!WIFEXITED(w))
! #define WEXITSTATUS(w) (w)
! #define WTERMSIG(w) (w)
#define sigmask(sig) ( 1 << ((sig)-1) )
--- 140,165
* Descriptions - http://www.comp.nus.edu.sg/~wuyongzh/my_doc/ntstatus.txt
* MS SDK - http://www.nologs.com/ntstatus.html
*
! * Because FormatMessage only handles NT_ERROR strings, and assumes they
! * do not have the 0xC prefix, we strip it to match this list:
! * http://msdn2.microsoft.com/en-us/library/ms681381.aspx
! *
! * When using FormatMessage():
! *
! * On MinGW, system() returns STATUS_* v
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 PostgreSQL > developers, not ordinary users. > When ordinary users encounter an Win32 exception, what they can do is > to report the message and the description of phenomenon to PostgreSQL > developers. What can they do when they see the descriptive text of an > exception code, such as "Access violation" for 0xC005? An > exception means a bug of PostgreSQL. Win32 exceptions are different > from errno on UNIX (counterpart of which is Win32 error code.) Can > they avoid the exception by changing PostgreSQL settings? If luckly > so in one case, can they think of the treatment from the message? > > If "people" means PostgreSQL developers, the descriptive text is not > necessary either. I think the developers who try to solve the bug > know where to refer to interpret the exception code. > > My opinion is the same as Tom-san's. Well, I am thinking of cases where we the error can help the user diagnose the problem. I have found a way to print descriptions with FormatMessage(), and the codes without descriptions will just print as hex. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 ordinary users encounter an Win32 exception, what they can do is to report the message and the description of phenomenon to PostgreSQL developers. What can they do when they see the descriptive text of an exception code, such as "Access violation" for 0xC005? An exception means a bug of PostgreSQL. Win32 exceptions are different from errno on UNIX (counterpart of which is Win32 error code.) Can they avoid the exception by changing PostgreSQL settings? If luckly so in one case, can they think of the treatment from the message? If "people" means PostgreSQL developers, the descriptive text is not necessary either. I think the developers who try to solve the bug know where to refer to interpret the exception code. My opinion is the same as Tom-san's. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 by now that putting copies of other peoples' code > in our tree isn't such a hot idea; what is going to cause it to be > updated when things change? How do you know the values are even the > same across all the Windows versions we support? > > Basically this whole idea is misconceived. Just print the number and > have done. And how do people interpret that number? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 other peoples' code in our tree isn't such a hot idea; what is going to cause it to be updated when things change? How do you know the values are even the same across all the Windows versions we support? Basically this whole idea is misconceived. Just print the number and have done. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 we stick mingw stuff in there, people > > looking for mingw might miss it.. > > 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? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 > >>> * Descriptions - > >>> http://www.comp.nus.edu.sg/~wuyongzh/my_doc/ntstatus.txt > >>> * MS SDK - http://www.nologs.com/ntstatus.html > >> I don't have a problem with mentioning those in a source code comment. > >> I question the wisdom of putting any of them in the error message ... > >> especially seeing that you haven't even found an "official" Microsoft > >> page to link to. None of those look to me like they're stable enough > >> to expect to still be there in three or four years. > > > > 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 we stick mingw stuff in there, people > looking for mingw might miss it.. OK, maybe /doc or src/tools. A more radical approach would be to put the list in our documentation, or have initdb install it. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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://www.comp.nus.edu.sg/~wuyongzh/my_doc/ntstatus.txt >>> * MS SDK - http://www.nologs.com/ntstatus.html >> I don't have a problem with mentioning those in a source code comment. >> I question the wisdom of putting any of them in the error message ... >> especially seeing that you haven't even found an "official" Microsoft >> page to link to. None of those look to me like they're stable enough >> to expect to still be there in three or four years. > > 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 we stick mingw stuff in there, people looking for mingw might miss it.. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 documentation, but source code, which makes it less > appropriate. > >>> OK, so what suggestion do you have? I just proposed a few of them in my > >>> previous email. > >>> > >> A good place for the URL might be in the win32 specific FAQ? > > > > The list is 1160 lines long, though, so I think it deserves its own URL. > > > Yes. I meant putting the URL in the FAQ, not the contents of the list. Oh, hmmm, I don't think people like having the URL linking outside our control, and I tend to agree with that. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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/~wuyongzh/my_doc/ntstatus.txt > > * MS SDK - http://www.nologs.com/ntstatus.html > > I don't have a problem with mentioning those in a source code comment. > I question the wisdom of putting any of them in the error message ... > especially seeing that you haven't even found an "official" Microsoft > page to link to. None of those look to me like they're stable enough > to expect to still be there in three or four years. Agreed. I propose we put the file in src/tools/msvc and link to our CVS source tree or something. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 makes it less appropriate. >>> OK, so what suggestion do you have? I just proposed a few of them in my >>> previous email. >>> >> A good place for the URL might be in the win32 specific FAQ? > > The list is 1160 lines long, though, so I think it deserves its own URL. > Yes. I meant putting the URL in the FAQ, not the contents of the list. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 > >> appropriate. > > > > OK, so what suggestion do you have? I just proposed a few of them in my > > previous email. > > > > A good place for the URL might be in the win32 specific FAQ? The list is 1160 lines long, though, so I think it deserves its own URL. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 > * MS SDK - http://www.nologs.com/ntstatus.html I don't have a problem with mentioning those in a source code comment. I question the wisdom of putting any of them in the error message ... especially seeing that you haven't even found an "official" Microsoft page to link to. None of those look to me like they're stable enough to expect to still be there in three or four years. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
>>> 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 suggestion do you have? I just proposed a few of them in my > previous email. > A good place for the URL might be in the win32 specific FAQ? //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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's not the responsibility of that error message to tell someone to > > go look up the error number in Microsoft documentation. If they're > > clueful enough to make any sense of the number beyond the strerror > > translation we already provide, then they already know where to look. > > Well, it took me like 25 minutes to find that list, so it isn't obvious. > Search for STATUS_CARDBUS_NOT_SUPPORTED, and you get only 75 hits on > Google, and our URL is #7. One idea Andrew Dunstan had was to print > descriptions for the most popular values. I asked him to give it a try > once I applied this patch. > > > Even if it were the responsibility of the error message to suggest this, > > a URL seems far too transient. > > It is a URL to the Wine CVS repository, so I assume it will be around for > a while. One thing we could do is copy that file to a URL on our web > site and point error messages to that. We could put the file in our CVS > and point to that too. 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 * MS SDK - http://www.nologs.com/ntstatus.html -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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? > > > > It's not the responsibility of that error message to tell someone to > > go look up the error number in Microsoft documentation. If they're > > clueful enough to make any sense of the number beyond the strerror > > translation we already provide, then they already know where to look. > > > > 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 suggestion do you have? I just proposed a few of them in my previous email. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 error message to tell someone to > go look up the error number in Microsoft documentation. If they're > clueful enough to make any sense of the number beyond the strerror > translation we already provide, then they already know where to look. Well, it took me like 25 minutes to find that list, so it isn't obvious. Search for STATUS_CARDBUS_NOT_SUPPORTED, and you get only 75 hits on Google, and our URL is #7. One idea Andrew Dunstan had was to print descriptions for the most popular values. I asked him to give it a try once I applied this patch. > Even if it were the responsibility of the error message to suggest this, > a URL seems far too transient. It is a URL to the Wine CVS repository, so I assume it will be around for a while. One thing we could do is copy that file to a URL on our web site and point error messages to that. We could put the file in our CVS and point to that too. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 go look up the error number in Microsoft documentation. If they're clueful enough to make any sense of the number beyond the strerror translation we already provide, then they already know where to look. Even if it were the responsibility of the error message to suggest this, a URL seems far too transient. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 the URL in a errhint() > > instead? > > 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? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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? It should not be there at all. Do you see URLs in any of our other error messages? regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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?
>
> > + ereport(lev,
> > +
> > + /*--
> > + translator: %s is a noun phrase describing a child process,
> > such as
> > + "server process" */
> > + (errmsg("%s (PID %d) was terminated by
> > exception %X\nSee http://source.winehq.org/source/include/ntstatus.h for a
> > description\nof the hex value.",
> > + procname, pid,
> > WTERMSIG(exitstatus;
> > + #endif
Oops, forgot to mention that detail. We are using log_error() in one
case, and ereport() in another. Let me do the hint in the report case,
but I have to leave the log_error case alone because it takes only three
arguments.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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,
> +
> + /*--
> + translator: %s is a noun phrase describing a child process,
> such as
> + "server process" */
> + (errmsg("%s (PID %d) was terminated by
> exception %X\nSee http://source.winehq.org/source/include/ntstatus.h for a
> description\nof the hex value.",
> + procname, pid,
> WTERMSIG(exitstatus;
> + #endif
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
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 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, and everything above that as a
> signal exits. I also think it is too risky to backpatch to 8.2.X.
>
> Also, should we print Win32 WTERMSIG() values as hex because they are so
> large? I have added that to the patch.
>
> ---
>
> ITAGAKI Takahiro wrote:
> >
> > Tom Lane <[EMAIL PROTECTED]> wrote:
> >
> > > server process exited with exit code -1073741819
> > > from what I suspect is really the equivalent of a SIGSEGV trap,
> > > ie, attempted access to already-deallocated memory. My calculator
> > > says the above is equivalent to hex C005, and I say that this
> > > makes it pretty clear that *some* parts of Windows put flag bits into
> > > the process exit code. Anyone want to run down what we should really
> > > be using instead of the above macros?
> >
> > C005 equals to EXCEPTION_ACCESS_VIOLATION. The value returned by
> > GetExceptionCode() seems to be the exit code in unhandeled exception cases.
> >
> > AFAICS, all EXCEPTION_xxx (or STATUS_xxx) values are defined as 0xCxxx.
> > I think we can use the second high bit to distinguish exit by exception
> > from normal exits.
> >
> > #define WEXITSTATUS(w) ((int) ((w) & 0x4000))
> > #define WIFEXITED(w)((w) & 0x4000) == 0)
> > #define WIFSIGNALED(w) ((w) & 0x4000) != 0)
> > #define WTERMSIG(w) (w) // or ((w) & 0x3FFF)
> >
> > However, it comes from reverse engineering of the headers of Windows.
> > I cannot find any official documentation.
> >
> > Regards,
> > ---
> > ITAGAKI Takahiro
> > NTT Open Source Software Center
> >
> >
> >
> > ---(end of broadcast)---
> > TIP 3: Have you checked our extensive FAQ?
> >
> >http://www.postgresql.org/docs/faq
>
> --
> Bruce Momjian [EMAIL PROTECTED]
> EnterpriseDBhttp://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
> ---(end of broadcast)---
> TIP 5: don't forget to increase your free space map settings
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/postmaster/postmaster.c
===
RCS file: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.508
diff -c -c -r1.508 postmaster.c
*** src/backend/postmaster/postmaster.c 16 Jan 2007 13:28:56 - 1.508
--- src/backend/postmaster/postmaster.c 22 Jan 2007 18:29:01 -
***
*** 2421,2426
--- 2421,2427
(errmsg("%s (PID %d) exited with exit code %d",
procname, pid, WEXITSTATUS(exitstatus;
else if (WIFSIGNALED(exitstatus))
+ #ifndef WIN32
ereport(lev,
/*--
***
*** 2428,2433
--- 2429,2443
"server process" */
(errmsg("%s (PID %d) was terminated by signal %d",
procname, pid, WTERMSIG(exitstatus;
+ #else
+ ereport(lev,
+
+ /*--
+ translator: %s is a noun phrase describing a child process, such as
+ "server process" */
+ (errmsg("%s (PID %d) was terminated by exception %X\nSee http://source.winehq.org/source/include/ntstatus.h for a description\nof the hex value.",
+ procname, pid, WTERMSIG(exitstatus;
+ #endif
else
ereport(lev,
Index: src/include/port/win32.h
===
RCS file: /cvsroot/pgsql/src/include/port/win32.h,v
retrieving revision 1.65
diff -c -c -r1.65 win32.h
*** src/include/port/win32.h 11 Jan 2007 02:42:31 - 1.65
--- src/include/port/win32.h 22 Jan 2007 18:29:02 -
***
*** 115,130
/*
* Signal stuff
! * WIN32 doesn't have wait(), so the return value for children
! * is simply the return value specified by the child, without
! * any additional information on whether the child terminated
! * on its own or via a signal. These macros are also used
! * to interpret the return value of system().
! */
! #define WEXITSTATUS(w) (w)
! #define WIFEXITED(w) (true)
! #define WIFSIGNALED(w) (false)
! #define WTERMSIG(w) (0)
#define sigmask(sig) ( 1 << ((sig)-1) )
--- 115,152
/*
* Signal stuff
! *
! * For WIN32, there is no wait() call so there are no wait() macros
! * to interpr
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too simplistic
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, and everything above that as a
signal exits. I also think it is too risky to backpatch to 8.2.X.
Also, should we print Win32 WTERMSIG() values as hex because they are so
large? I have added that to the patch.
---
ITAGAKI Takahiro wrote:
>
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > server process exited with exit code -1073741819
> > from what I suspect is really the equivalent of a SIGSEGV trap,
> > ie, attempted access to already-deallocated memory. My calculator
> > says the above is equivalent to hex C005, and I say that this
> > makes it pretty clear that *some* parts of Windows put flag bits into
> > the process exit code. Anyone want to run down what we should really
> > be using instead of the above macros?
>
> C005 equals to EXCEPTION_ACCESS_VIOLATION. The value returned by
> GetExceptionCode() seems to be the exit code in unhandeled exception cases.
>
> AFAICS, all EXCEPTION_xxx (or STATUS_xxx) values are defined as 0xCxxx.
> I think we can use the second high bit to distinguish exit by exception
> from normal exits.
>
> #define WEXITSTATUS(w) ((int) ((w) & 0x4000))
> #define WIFEXITED(w)((w) & 0x4000) == 0)
> #define WIFSIGNALED(w) ((w) & 0x4000) != 0)
> #define WTERMSIG(w) (w) // or ((w) & 0x3FFF)
>
> However, it comes from reverse engineering of the headers of Windows.
> I cannot find any official documentation.
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
>
>
>
> ---(end of broadcast)---
> TIP 3: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/docs/faq
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/postmaster/postmaster.c
===
RCS file: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.508
diff -c -c -r1.508 postmaster.c
*** src/backend/postmaster/postmaster.c 16 Jan 2007 13:28:56 - 1.508
--- src/backend/postmaster/postmaster.c 22 Jan 2007 04:51:01 -
***
*** 2426,2432
/*--
translator: %s is a noun phrase describing a child process, such as
"server process" */
! (errmsg("%s (PID %d) was terminated by signal %d",
procname, pid, WTERMSIG(exitstatus;
else
ereport(lev,
--- 2426,2432
/*--
translator: %s is a noun phrase describing a child process, such as
"server process" */
! (errmsg("%s (PID %d) was terminated by signal "PRINTF_SIGNUM,
procname, pid, WTERMSIG(exitstatus;
else
ereport(lev,
Index: src/include/c.h
===
RCS file: /cvsroot/pgsql/src/include/c.h,v
retrieving revision 1.216
diff -c -c -r1.216 c.h
*** src/include/c.h 11 Jan 2007 02:39:52 - 1.216
--- src/include/c.h 22 Jan 2007 04:51:02 -
***
*** 788,793
--- 788,800
#define SIGNAL_ARGS int postgres_signal_arg
#endif
+ #ifndef WIN32
+ #define PRINTF_SIGNUM "%d"
+ #else
+ /* Win32 non-exit system() return values are high, see port/win32.h */
+ #define PRINTF_SIGNUM "%X"
+ #endif
+
/*
* When there is no sigsetjmp, its functionality is provided by plain
* setjmp. Incidentally, nothing provides setjmp's functionality in
Index: src/include/port/win32.h
===
RCS file: /cvsroot/pgsql/src/include/port/win32.h,v
retrieving revision 1.65
diff -c -c -r1.65 win32.h
*** src/include/port/win32.h 11 Jan 2007 02:42:31 - 1.65
--- src/include/port/win32.h 22 Jan 2007 04:51:02 -
***
*** 115,130
/*
* Signal stuff
! * WIN32 doesn't have wait(), so the return value for children
! * is simply the return value specified by the child, without
! * any additional information on whether the child terminated
! * on its own or via a signal. These macros are also used
! * to interpret the return value of system().
! */
! #define WEXITSTATUS(w) (w)
! #define WIFEXITED(w) (true)
! #define WIFSIGNALED(w) (false)
! #define WTERMSIG(w) (0)
#define sigmask(sig) ( 1 << ((sig)-1) )
--- 115,134
/*
* Signal stuff
! * For WIN32, there is no wait() call so there are no wait() macros
! * to interpret the return value of system(). Instead, system()
! * return values < 0x100 are used for exit() termination, and higher
! * values are used to indicated non-exit() termination, which is
! * similar to a u
