Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit e02ea14

Browse files
committed
Try again to work around Windows' ERROR_SHARING_VIOLATION in pg_ctl.
Commit 0da33c7 introduced an unfortunate regression in pg_ctl on Windows: if the log file specified with -l doesn't exist yet, and pg_ctl is running with Administrator privileges, then the log file might get created with permissions that prevent the postmaster from writing on it. (It seems that whether this happens depends on whether the log file is inside the user's home directory or not, and perhaps on other phase-of-the-moon conditions, which may explain why we failed to notice it sooner.) To fix, just don't create the log file if it doesn't exist yet. The case where we need to wait obviously only occurs with a pre-existing log file. In passing, switch from using fopen() to plain open(), saving a few cycles. Per bug #16259 from Jonathan Katz and Heath Lord. Back-patch to v12, as the faulty commit was. Alexander Lakhin Discussion: https://postgr.es/m/16259-c5ebed32a262a8b1@postgresql.org
1 parent faade5d commit e02ea14

File tree

1 file changed

+21
-7
lines changed

1 file changed

+21
-7
lines changed

src/bin/pg_ctl/pg_ctl.c

Lines changed: 21 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -521,23 +521,37 @@ start_postmaster(void)
521521
if (log_file != NULL)
522522
{
523523
/*
524-
* First, touch the log file. The main value of this is that if the
524+
* First, open the log file if it exists. The idea is that if the
525525
* file is still locked by a previous postmaster run, we'll wait until
526526
* it comes free, instead of failing with ERROR_SHARING_VIOLATION.
527527
* (It'd be better to open the file in a sharing-friendly mode, but we
528528
* can't use CMD.EXE to do that, so work around it. Note that the
529529
* previous postmaster will still have the file open for a short time
530530
* after removing postmaster.pid.)
531+
*
532+
* If the log file doesn't exist, we *must not* create it here. If we
533+
* were launched with higher privileges than the restricted process
534+
* will have, the log file might end up with permissions settings that
535+
* prevent the postmaster from writing on it.
531536
*/
532-
FILE *fd = fopen(log_file, "a");
537+
int fd = open(log_file, O_RDWR, 0);
533538

534-
if (fd == NULL)
539+
if (fd == -1)
535540
{
536-
write_stderr(_("%s: could not create log file \"%s\": %s\n"),
537-
progname, log_file, strerror(errno));
538-
exit(1);
541+
/*
542+
* ENOENT is expectable since we didn't use O_CREAT. Otherwise
543+
* complain. We could just fall through and let CMD.EXE report
544+
* the problem, but its error reporting is pretty miserable.
545+
*/
546+
if (errno != ENOENT)
547+
{
548+
write_stderr(_("%s: could not open log file \"%s\": %s\n"),
549+
progname, log_file, strerror(errno));
550+
exit(1);
551+
}
539552
}
540-
fclose(fd);
553+
else
554+
close(fd);
541555

542556
snprintf(cmd, MAXPGPATH, "\"%s\" /C \"\"%s\" %s%s < \"%s\" >> \"%s\" 2>&1\"",
543557
comspec, exec_path, pgdata_opt, post_opts, DEVNULL, log_file);

0 commit comments

Comments
 (0)