On Mon, Sep 3, 2012 at 12:44:09PM -0400, Andrew Dunstan wrote: > The attached very small patch allows pg_upgrade's "make check" to > succeed on REL9_2_STABLE on my Mingw system. > > However, I consider the issue I mentioned earlier regarding use of > forward slashes in the argument to rmdir to be a significant > blocker, so I'm going to go and fix that and then pull this all > together. > > cheers > > andrew
> diff --git a/contrib/pg_upgrade/exec.c b/contrib/pg_upgrade/exec.c > index 6f993df..57ca1df 100644 > --- a/contrib/pg_upgrade/exec.c > +++ b/contrib/pg_upgrade/exec.c > @@ -91,10 +91,12 @@ exec_prog(bool throw_error, bool is_priv, const char > *log_file, > else > retval = 0; > > +#ifndef WIN32 > if ((log = fopen_priv(log_file, "a+")) == NULL) > pg_log(PG_FATAL, "cannot write to log file %s\n", log_file); > fprintf(log, "\n\n"); > fclose(log); > +#endif > > return retval; > } I am confused by this fix. If pg_ctl was keeping that log file open, wouldn't the log write fail when pg_dump or psql was run later? I am trying to understand how a later commands would not also trigger an error. Is it a timing thing? If that is it, I would like to know and have that documented. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
