On 09/04/2012 09:47 AM, Bruce Momjian wrote:
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.
Oh, hmm. I thought it was the postmaster holding the log, but now I see
that we are giving it a different log file. Maybe it is a timing thing.
I'll experiment and see if a sleep cures the problem.
...
Nope, still getting this after a sleep(5):
cannot write to log file pg_upgrade_server_start.log
Failure, exiting
...
[try some more] Nope, even in a loop lasting 60s I still got this.
So I'm a bit confused too. Seeing if I can narrow it down using ProcMon ...
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
