pgsql: In pg_ctl, work around ERROR_SHARING_VIOLATION on the postmaster

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: In pg_ctl, work around ERROR_SHARING_VIOLATION on the postmaster
Date: 2019-12-10 18:17:21
Message-ID: E1iek4X-0002J9-Uy@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

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

Branch
------
REL_12_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/be9d4b9280606a0b0984ba46c452a48961cf92d4

Modified Files
--------------
src/bin/pg_ctl/pg_ctl.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2019-12-10 20:14:20 pgsql: Add backend-only appendStringInfoStringQuoted
Previous Message Etsuro Fujita 2019-12-10 09:30:35 pgsql: Fix handling of multiple AFTER ROW triggers on a foreign table.