Re: pgsql: Get rid of backtracking in jsonpath_scan.l

2019-03-26 Thread Tom Lane
Alvaro Herrera  writes:
> On 2019-Mar-26, Tom Lane wrote:
>> Alvaro Herrera  writes:
>>> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55

>> I've never cared for the ntstatus.h reference, but how stable is
>> the URL you suggest going to be?  That UUID or whatever it is
>> does not inspire confidence.

> That's true.  Before posting, I looked for a statement about URL
> stability, couldn't find anything.  I suppose one currently working URL
> is better than four currently dead URLs.

It looks like we could just point to the parent page,

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/

That requires a little more drilling down, but it seems likely to
remain stable across versions, whereas I strongly suspect the URL
you mention is version-specific.

regards, tom lane




Re: pgsql: Get rid of backtracking in jsonpath_scan.l

2019-03-26 Thread Alvaro Herrera
On 2019-Mar-26, Tom Lane wrote:

> Alvaro Herrera  writes:
> >> 0xC028 is STATUS_BAD_STACK, per
> >> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
> >> Not sure how credible/useful a stack trace is going to be.
> 
> > BTW I think we should update our message to use this URL instead of
> > ambiguously pointing to "ntstatus.h".
> 
> I've never cared for the ntstatus.h reference, but how stable is
> the URL you suggest going to be?  That UUID or whatever it is
> does not inspire confidence.

That's true.  Before posting, I looked for a statement about URL
stability, couldn't find anything.  I suppose one currently working URL
is better than four currently dead URLs.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: pgsql: Get rid of backtracking in jsonpath_scan.l

2019-03-26 Thread Tom Lane
Alvaro Herrera  writes:
>> 0xC028 is STATUS_BAD_STACK, per
>> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
>> Not sure how credible/useful a stack trace is going to be.

> BTW I think we should update our message to use this URL instead of
> ambiguously pointing to "ntstatus.h".

I've never cared for the ntstatus.h reference, but how stable is
the URL you suggest going to be?  That UUID or whatever it is
does not inspire confidence.

regards, tom lane



Re: pgsql: Get rid of backtracking in jsonpath_scan.l

2019-03-26 Thread Andrew Dunstan


On 3/26/19 12:53 PM, Alvaro Herrera wrote:
> On 2019-Mar-26, Alvaro Herrera wrote:
>
>>> 2019-03-26 00:49:02.208 EDT [5c99ae9e.20cc:6] LOG:  server process (PID 
>>> 8368) was terminated by exception 0xC028
>> 0xC028 is STATUS_BAD_STACK, per
>> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
>> Not sure how credible/useful a stack trace is going to be.
> BTW I think we should update our message to use this URL instead of
> ambiguously pointing to "ntstatus.h".  Also, all the URLs in
> win32_port.h (except the wine one) are dead.
>


That's a fairly awful URL. How stable is it likely to be?


cheers


andrew

-- 
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




Re: pgsql: Get rid of backtracking in jsonpath_scan.l

2019-03-26 Thread Alvaro Herrera
On 2019-Mar-26, Alvaro Herrera wrote:

> > 2019-03-26 00:49:02.208 EDT [5c99ae9e.20cc:6] LOG:  server process (PID 
> > 8368) was terminated by exception 0xC028
> 
> 0xC028 is STATUS_BAD_STACK, per
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
> Not sure how credible/useful a stack trace is going to be.

BTW I think we should update our message to use this URL instead of
ambiguously pointing to "ntstatus.h".  Also, all the URLs in
win32_port.h (except the wine one) are dead.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/postmaster/pgarch.c b/src/backend/postmaster/pgarch.c
index f84f882c4cb..549c82ea627 100644
--- a/src/backend/postmaster/pgarch.c
+++ b/src/backend/postmaster/pgarch.c
@@ -647,7 +647,8 @@ pgarch_archiveXlog(char *xlog)
 			ereport(lev,
 	(errmsg("archive command was terminated by exception 0x%X",
 			WTERMSIG(rc)),
-	 errhint("See C include file \"ntstatus.h\" for a description of the hexadecimal value."),
+	 errhint("See \"%s\" for a description of the hexadecimal value.",
+			 "https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55";),
 	 errdetail("The failed archive command was: %s",
 			   xlogarchcmd)));
 #else
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index fe599632d3d..a540d51d79a 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -3630,7 +3630,8 @@ LogChildExit(int lev, const char *procname, int pid, int exitstatus)
 		  "server process" */
 (errmsg("%s (PID %d) was terminated by exception 0x%X",
 		procname, pid, WTERMSIG(exitstatus)),
- errhint("See C include file \"ntstatus.h\" for a description of the hexadecimal value."),
+ errhint("See \"%s\" for a description of the hexadecimal value.",
+		 "https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55";),
  activity ? errdetail("Failed process was running: %s", activity) : 0));
 #else
 		ereport(lev,
diff --git a/src/include/port/win32_port.h b/src/include/port/win32_port.h
index f4841fb3975..12abd08cda4 100644
--- a/src/include/port/win32_port.h
+++ b/src/include/port/win32_port.h
@@ -107,7 +107,7 @@
  *	similar to a unix-style signal exit (think SIGSEGV ==
  *	STATUS_ACCESS_VIOLATION).  Return values are broken up into groups:
  *
- *	http://msdn2.microsoft.com/en-gb/library/aa489609.aspx
+ *	https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/87fba13e-bf06-450e-83b1-9241dc81e781
  *
  *		NT_SUCCESS			0 - 0x3FFF
  *		NT_INFORMATION		0x4000 - 0x7FFF
@@ -119,24 +119,10 @@
  *	by the system, and it seems values >= 0x100 are system-generated.
  *	See this URL for a list of WIN32 STATUS_* values:
  *
- *		Wine (URL used in our error messages) -
+ *		https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
+ *
+ *		Wine -
  *			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
- *
- *	It seems the exception lists are in both ntstatus.h and winnt.h, but
- *	ntstatus.h has a more comprehensive list, and it only contains
- *	exception values, rather than winnt, which contains lots of other
- *	things:
- *
- *		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.
  *
  *	Some day we might want to print descriptions for the most common
  *	exceptions, rather than printing an include file name.  We could use