Re: Win32 testing needed

Tom Lane <[email protected]>
Newsgroups gmane.comp.db.postgresql.devel.win32
Message-ID <[email protected]>
Andreas Pflug <[email protected]> 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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.