Thread: Re: [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 <alvherre@commandprompt.com> 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 bruce@momjian.us > EnterpriseDB http://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 bruce@momjian.us EnterpriseDB http://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 -0000 1.510 --- src/backend/postmaster/postmaster.c 23 Jan 2007 01:43:22 -0000 *************** *** 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 -0000 1.67 --- src/include/port/win32.h 23 Jan 2007 01:43:23 -0000 *************** *** 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) & 0XFFFFFF00) == 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_* 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 ! * 0xC0000005 == STATUS_ACCESS_VIOLATION, and 0x5 is a value ! * FormatMessage() can look up. GetLastError() does not work; ! * always zero. ! */ ! #define STATUS_ERROR_MASK 0xC0000000 ! #define WIFEXITED(w) (((w) & 0XFFFFFF00) == 0) ! #define WIFSIGNALED(w) (!WIFEXITED(w)) ! #define WEXITSTATUS(w) (w) ! #define WERRORCODE(w) ((((w) & STATUS_ERROR_MASK) == STATUS_ERROR_MASK) ? \ ! ((w) & ~STATUS_ERROR_MASK) : 0) #define sigmask(sig) ( 1 << ((sig)-1) ) Index: src/port/exec.c =================================================================== RCS file: /cvsroot/pgsql/src/port/exec.c,v retrieving revision 1.45 diff -c -c -r1.45 exec.c *** src/port/exec.c 22 Jan 2007 18:31:51 -0000 1.45 --- src/port/exec.c 23 Jan 2007 01:43:24 -0000 *************** *** 586,593 **** log_error(_("child process was terminated by signal %d"), WTERMSIG(exitstatus)); #else ! log_error(_("child process was terminated by exception %X\nSee http://source.winehq.org/source/include/ntstatus.hfor a description\nof the hex value."), ! WTERMSIG(exitstatus)); #endif else log_error(_("child process exited with unrecognized status %d"), --- 586,609 ---- log_error(_("child process was terminated by signal %d"), 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)); ! ! log_error(_("child process was terminated by the operating system\n%s"), ! last_system_error); ! } #endif else log_error(_("child process exited with unrecognized status %d"),
From: "Bruce Momjian" <bruce@momjian.us> > 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 ! * 0xC0000005 == 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, 0xC0000005 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 0xC0000005 (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 0xC000008E (STATUS_FLOAT_DIVIDE_BY_ZERO), I think. 0x8E is ERROR_BUSY_DRIVE.
Takayuki Tsunakawa wrote:
> From: "Bruce Momjian" <bruce@momjian.us>
> > 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
> ! * 0xC0000005 == 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, 0xC0000005 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 0xC0000005 (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 0xC000008E
> (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 bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From: "Bruce Momjian" <bruce@momjian.us> 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" <bruce@momjian.us> To: "Takayuki Tsunakawa" <tsunakawa.takay@jp.fujitsu.com> Cc: "PostgreSQL-patches" <pgsql-patches@postgresql.org>; "Tom Lane" <tgl@sss.pgh.pa.us>; "Alvaro Herrera" <alvherre@commandprompt.com>; "Magnus Hagander" <magnus@hagander.net>; "ITAGAKI Takahiro" <itagaki.takahiro@oss.ntt.co.jp> Sent: Tuesday, January 23, 2007 12:35 PM Subject: Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too > Takayuki Tsunakawa wrote: >> From: "Bruce Momjian" <bruce@momjian.us> >> > 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 >> ! * 0xC0000005 == 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, 0xC0000005 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 0xC0000005 (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 0xC000008E >> (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 bruce@momjian.us > EnterpriseDB http://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 >
Takayuki Tsunakawa wrote: > From: "Bruce Momjian" <bruce@momjian.us> > 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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
> Takayuki Tsunakawa wrote:
>> From: "Bruce Momjian" <bruce@momjian.us>
>> 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/
On Mon, Jan 22, 2007 at 10:35:11PM -0500, Bruce Momjian wrote: > Takayuki Tsunakawa wrote: > > From: "Bruce Momjian" <bruce@momjian.us> > > > 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 > > ! * 0xC0000005 == 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, 0xC0000005 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 0xC0000005 (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 0xC000008E > > (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
From: "Magnus Hagander" <magnus@hagander.net> > 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?
On Tue, Jan 23, 2007 at 06:50:06PM +0900, Takayuki Tsunakawa wrote: > From: "Magnus Hagander" <magnus@hagander.net> > > 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
Magnus Hagander wrote: > On Tue, Jan 23, 2007 at 06:50:06PM +0900, Takayuki Tsunakawa wrote: > > From: "Magnus Hagander" <magnus@hagander.net> > > > 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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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" <magnus@hagander.net> > > > > 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
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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
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 0xc0000005 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 bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> 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
Takayuki Tsunakawa wrote: > From: "Magnus Hagander" <magnus@hagander.net> > > 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 0xC0000005. 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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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 0xc0000005 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
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> 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) 0x00000000) 37 #define STATUS_WAIT_1 ((NTSTATUS) 0x00000001) 38 #define STATUS_WAIT_2 ((NTSTATUS) 0x00000002) 39 #define STATUS_WAIT_3 ((NTSTATUS) 0x00000003) 40 #define STATUS_WAIT_63 ((NTSTATUS) 0x0000003f) 41 #define STATUS_ABANDONED ((NTSTATUS) 0x00000080) 42 #define STATUS_ABANDONED_WAIT_0 ((NTSTATUS) 0x00000080) 43 #define STATUS_ABANDONED_WAIT_63 ((NTSTATUS) 0x000000BF) 44 #define STATUS_USER_APC ((NTSTATUS) 0x000000C0) > 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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Tue, Jan 23, 2007 at 10:32:58AM -0500, Bruce Momjian wrote: > Takayuki Tsunakawa wrote: > > From: "Magnus Hagander" <magnus@hagander.net> > > > 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 > 0xC0000005. 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
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 0xc0000005 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 > 0xC0000000 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 bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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 > 0xC0000000 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
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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 > 0xC0000000 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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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: pgsql-patches-owner@postgresql.org [mailto:pgsql-patches-owner@postgresql.org] 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 <bruce@momjian.us> 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?
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
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: pgsql-patches-owner@postgresql.org > [mailto:pgsql-patches-owner@postgresql.org] 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 <bruce@momjian.us> 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 majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +