Hi,

We've seen several cases of people (running 8.1 or 8.2) that see
messages like this:

2007-11-26 11:41:59 ERROR:  could not open relation 1663/352369/353685: Invalid 
argument

The platform is Win32.

The problem is that pgwin32_open reduces any error code from
GetLastError that's not ERROR_PATH_NOT_FOUND, ERROR_FILE_NOT_FOUND,
ERROR_FILE_EXISTS or ERROR_ACCESS_DENIED into EINVAL, without further
notice.  This is problematic because the true cause of the problem is
being hidden and it's hard to track down what's going on.

Can we do something like this to report the Win32 error code so that the
user has a higher chance of figuring out what's going on?

-- 
Alvaro Herrera                          Developer, http://www.PostgreSQL.org/
"Las navajas y los monos deben estar siempre distantes"   (Germán Poo)
Index: src/port/open.c
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/src/port/open.c,v
retrieving revision 1.21
diff -c -p -r1.21 open.c
*** src/port/open.c	15 Nov 2007 21:14:46 -0000	1.21
--- src/port/open.c	28 Nov 2007 14:56:04 -0000
*************** pgwin32_open(const char *fileName, int f
*** 88,94 ****
  						((fileFlags & O_DSYNC) ? FILE_FLAG_WRITE_THROUGH : 0),
  						NULL)) == INVALID_HANDLE_VALUE)
  	{
! 		switch (GetLastError())
  		{
  				/* EMFILE, ENFILE should not occur from CreateFile. */
  			case ERROR_PATH_NOT_FOUND:
--- 88,96 ----
  						((fileFlags & O_DSYNC) ? FILE_FLAG_WRITE_THROUGH : 0),
  						NULL)) == INVALID_HANDLE_VALUE)
  	{
! 		DWORD	err = GetLastError();
! 
! 		switch (err)
  		{
  				/* EMFILE, ENFILE should not occur from CreateFile. */
  			case ERROR_PATH_NOT_FOUND:
*************** pgwin32_open(const char *fileName, int f
*** 102,107 ****
--- 104,111 ----
  				errno = EACCES;
  				break;
  			default:
+ 				ereport(LOG,
+ 						(errmsg("win32 error code: %d", err)));
  				errno = EINVAL;
  		}
  		return -1;
---------------------------(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

Reply via email to