Re: Win32 testing needed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
Cc: pgsql-hackers-win32(at)postgresql(dot)org, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: Re: Win32 testing needed
Date: 2004-08-06 16:59:01
Message-ID: 20388.1091811541@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32

Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
> Maybe we should consider examining GetLastError() and FormatMessage()
> (the equivalent of strerror, a sample is in the symlink/junction code)
> for %m under win32; these will work for standard posix operations also
> and might give much more detailed messages in many situations.

Hmm. It's a bit attractive but it would break a lot of existing code
that assumes saving/restoring errno is a sufficient way to not clobber
the error result info between getting an error and reporting it. For
instance, xlog.c has several repetitions of this pattern:

errno = 0;
if ((int) write(fd, zbuffer, sizeof(zbuffer)) != (int) sizeof(zbuffer))
{
int save_errno = errno;

/*
* If we fail to make the file, delete it to release disk
* space
*/
unlink(tmppath);
/* if write didn't set errno, assume problem is no disk space */
errno = save_errno ? save_errno : ENOSPC;

ereport(PANIC,
(errcode_for_file_access(),
errmsg("could not write to file \"%s\": %m", tmppath)));
}

and I don't think I want to add Windows #ifdefs to every such place.

What would be more supportable is something that assigns a suitable
value to errno after a failure of a Windows-specific call. Thus
something like

if (!ReadFile(syslogPipe[0], logbuffer, sizeof(logbuffer),
&bytesRead, 0))
{
DWORD error = GetLastError();

if (error == ERROR_HANDLE_EOF ||
error == ERROR_BROKEN_PIPE)
break;
errno = Win32ErrorToErrno(error);
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not read from logger pipe: %m")));
}

While this is admittedly ugly, it confines the ugliness to the fairly
small number of places where we call Windows-specific routines (ie,
we're already inside an #ifdef WIN32). If we do the other, the
messiness is going to spread into what had been perfectly good
Posix-standard code.

regards, tom lane

In response to

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Tom Lane 2004-08-06 17:25:50 Re: Win32 testing needed
Previous Message Tom Lane 2004-08-06 16:48:48 Re: Win32 testing needed