diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2019-12-10 13:17:08 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2019-12-10 13:17:08 -0500 |
commit | be9d4b9280606a0b0984ba46c452a48961cf92d4 (patch) | |
tree | 4e69348ac25ac168d802e4cd65e518fc2a0aa817 /src/backend/access/gist/gist.c | |
parent | 547e454cbc8f8896b535cf2debd61b2c5701d8c0 (diff) | |
download | postgresql-be9d4b9280606a0b0984ba46c452a48961cf92d4.tar.gz postgresql-be9d4b9280606a0b0984ba46c452a48961cf92d4.zip |
In pg_ctl, work around ERROR_SHARING_VIOLATION on the postmaster log file.
On Windows, we use CMD.EXE to redirect the postmaster's stdout/stderr
into a log file. CMD.EXE will open that file with non-sharing-friendly
parameters, and the file will remain open for a short time after the
postmaster has removed postmaster.pid. This can result in an
ERROR_SHARING_VIOLATION failure if we attempt to start a new postmaster
immediately with the same log file (e.g. during "pg_ctl restart").
This seems to explain intermittent buildfarm failures we've been seeing
on Windows machines.
To fix, just open and close the log file using our own pgwin32_open(),
which will wait if necessary to avoid the failure. (Perhaps someday
we should stop using CMD.EXE, but that would be a far more complex
patch, and it doesn't seem worth the trouble ... yet.)
Back-patch to v12. This only solves the problem when frontend fopen()
is redirected to pgwin32_fopen(), which has only been true since commit
0ba06e0bf. Hence, no point in back-patching further, unless we care
to back-patch that change too.
Diagnosis and patch by Alexander Lakhin (bug #16154).
Discussion: https://postgr.es/m/16154-1ccf0b537b24d5e0@postgresql.org
Diffstat (limited to 'src/backend/access/gist/gist.c')
0 files changed, 0 insertions, 0 deletions