Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iiA6C-0004J2-JW for pgsql-bugs@arkaria.postgresql.org; Fri, 20 Dec 2019 04:41:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iiA5D-0003Uf-21 for pgsql-bugs@arkaria.postgresql.org; Fri, 20 Dec 2019 04:40:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iiA5C-0003ST-Nd for pgsql-bugs@lists.postgresql.org; Fri, 20 Dec 2019 04:40:10 +0000 Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iiA55-0004hw-KT for pgsql-bugs@lists.postgresql.org; Fri, 20 Dec 2019 04:40:09 +0000 Received: by mail-lf1-x12c.google.com with SMTP id r14so5984112lfm.5 for ; Thu, 19 Dec 2019 20:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=DOhbU7FQgyW8wcEw0T+YOkiotFZ0CmMpH46b/0vB4J8=; b=AopwlhLNe/GIDE58pT7YQNnvPTw7+uAC1KLmEIK+LCftQHmokBuNi+7KXOmf97mri1 78LJGIllX9U1QiWg2owTQSgQRWBMUUj4585gVK1dfk+52IEnICOnNBjXK8qbwYnBOTNd 1rico4QnQ+Myt52wa7J6hVeP06vOz8bltoq+SpsylqRsxYy/Gr/8SA3fxf+HcFbcUbws YvTqeJe2x2hN3t8ktpeoTInJcJL6eNTCmFSpudvMUsHmVg4AxR5RxfaNmFPYi+AC0s02 R8OwV3PAcbnOsV6QVhjPt4O7tOAX9pUKUvDv62kGwSYAH4gzpDFjo7K9UF90kVffs2Nx aP0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=DOhbU7FQgyW8wcEw0T+YOkiotFZ0CmMpH46b/0vB4J8=; b=LmrEQAQvWbXqjPpvyWfsI20BBTBkfV1vMVIA3g4pYVafJYtrORqFJOIPzb65y8xafZ LHh/dAv4l9I3+J2+C31WoT4m7V4Nb8UbK+uSr1GW2zex45Q7BqOqC20LiZjwoIp7VVxL lAMIJgh3rh1SvZ7b1jJvZDvg4oTisranFDoxbfBNMRGlwyLOBZtP9JPJHo25rZoFCjvF 33bRzzpOWiSaPTI/ZvOzHZZQM21LjNNIn9wzR5wlp2/7vtd9P212ewbYhx4BpBYGz3Oy mGQFhU0mBMQBKnxu/07GLfadMlEcYVoexkusZ6CrYYpfEGSD+6JwOHkH1dgQw9k4b9fp hSyg== X-Gm-Message-State: APjAAAWn2H8y29G63I35hJ+siCjkcTkL1Mjbj+pJxsJjilpkNZSGWDnk +elm8nb3Shf1GfvTYZtRrLI7VM1X X-Google-Smtp-Source: APXvYqxxe+PukGGQFkOAdPSB1gxLX1Ph0+hawPXzYy3/3BGYBfRq01WTxCX8KzE7KMmQW27HU3OaDQ== X-Received: by 2002:ac2:44d9:: with SMTP id d25mr7867887lfm.15.1576816802232; Thu, 19 Dec 2019 20:40:02 -0800 (PST) Received: from [1.0.0.7] ([178.155.4.214]) by smtp.gmail.com with ESMTPSA id l21sm3421788lfh.74.2019.12.19.20.40.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Dec 2019 20:40:01 -0800 (PST) Subject: Re: BUG #16161: pg_ctl stop fails sometimes (on Windows) To: Kyotaro Horiguchi Cc: tgl@sss.pgh.pa.us, pgsql-bugs@lists.postgresql.org References: <5c7eaa87-8670-2008-3a15-337c133c12c2@gmail.com> <12599.1576786185@sss.pgh.pa.us> <20191220.123237.432497214732463092.horikyota.ntt@gmail.com> From: Alexander Lakhin Message-ID: <37483c7c-a202-fd12-7211-42aeb83bcfd7@gmail.com> Date: Fri, 20 Dec 2019 07:40:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20191220.123237.432497214732463092.horikyota.ntt@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 20.12.2019 6:32, Kyotaro Horiguchi wrote: > At Fri, 20 Dec 2019 05:40:00 +0300, Alexander Lakhin wrote in >> 19.12.2019 23:09, Tom Lane wrote: >>> Alexander Lakhin writes: >>>> Maybe we should change the condition to 'if (stat(fileName, &st) != 0 && >>>> (err = GetLastError()) == ERROR_ACCESS_DENIED)' to avoid unnecessary >>>> sleep with a loop iteration... >>> Well, we have to loop back on file-not-found too ... >> I think, if the file is not found on stat() we can safely return the >> updated err (set errno with _dosmapper(err), to be exact). If we'll loop >> back, we'll get the same err = GetLastError() after next CreateFile(). > I think Tom is mentinoing for O_CREAT case. If CreateFile returned > ERROR_ACCESS_DENIED, then stat() returns ERROR_FILE_NOT_FOUND, it > means the next CreateFile can success. It seems this is a new corner case and we just failed in this case previously (yes, with ERROR_ACCESS_DENIED instead of ERROR_FILE_NOT_FOUND, but nonetheless). If we restrict ourselves to solving the initial problem with 'pt_ctl stop' (and pg_ctl opens pidfile without O_CREAT), I wouldn't develop more powerful open() now. But if we want it, the following code passes my tests (restart & recoverycheck) too:                 if (stat(fileName, &st) != 0 &&                     ((err = GetLastError()) == ERROR_ACCESS_DENIED) ||                      ((err == ERROR_FILE_NOT_FOUND) && (fileFlags & O_CREAT)))                 {                     pg_usleep(100000);                     loops++;                     continue;                 } Maybe we still need a practical case where it's useful, to test it for sure. Best regards, Alexander