pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Жарков Роман <r.zharkov@postgrespro.ru>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Badrul Chowdhury <bachow@microsoft.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Intermittent pg_ctl failures on Windows
Date: Fri, 19 Jul 2019 12:00:37 +0700
Message-ID: <FE69ED0E-0232-406F-8712-16A92F55C53A@postgrespro.ru> (raw)
In-Reply-To: <20190719030208.GG1859@paquier.xyz>
References: <16922.1520722108@sss.pgh.pa.us>
	<DM5PR2101MB0984D3DB39BCCCF189ECD15ED1D30@DM5PR2101MB0984.namprd21.prod.outlook.com>
	<0057a0ce5a8893e4713a9a9d7e352162@postgrespro.ru>
	<26631.1563371508@sss.pgh.pa.us>
	<3b46fc8be044c79b5eff7d26c810d2fd@postgrespro.ru>
	<20190718085148.GI1416@paquier.xyz>
	<B9F855CF-1756-40FA-B9AF-1F48A9480269@postgrespro.ru>
	<20190719030208.GG1859@paquier.xyz>

First time we found pg_ctl errors while testing our fork.
I reproduced them on REL_11_STABLE.
I found three problems with pg_ctl do_stop/do_restart:
1 - "old" fopen() function;
2 - "delete pending" problem rarely happens with "new" fopen() function when pg_ctl tries to open postmaster.pid file;
3 - cmd.exe shell may block the log file when the server restarts;

Now i try to reproduce it on REL_12_STABLE

regard, Roman

> 19 июля 2019 г., в 10:02, Michael Paquier <michael@paquier.xyz> написал(а):
> 
>> On Thu, Jul 18, 2019 at 04:14:34PM +0700, Жарков Роман wrote:
>> I have tested clean REL_11_STABLE.
>> Commit f02259fe was reverted by df8b5f3e in this branch.
>> So pg_ctl uses “old” open() function.
> 
> Yeah, that was a failure from me, so I tend to be rather very careful
> about anything related to Windows.  However, after that we have added 
> 40cfe86 about which nobody has complained yet, and the number of
> buildfarm failures about pg_ctl concurrency on HEAD has gone down to
> zero since (perhaps I am missing something?).
> 
> So, instead of trying to invent a new solution only for stable
> branches (which may have its own bugs we would need to deal with only
> on stable branches, and only for Windows), why don't we just try to
> move forward into back-patching those pieces?  Or it happens that we
> still have some potential failures on HEAD and REL_12_STABLE which
> would justify some extra handling?  In this case, I would recommend
> that we focus on HEAD as a first step, and put things in order there.
> --
> Michael






view thread (16+ messages)  latest in thread

Message-ID: <FE69ED0E-0232-406F-8712-16A92F55C53A@postgrespro.ru>
Permalink:  ../FE69ED0E-0232-406F-8712-16A92F55C53A@postgrespro.ru/
Also on:    postgresql.org/message-id/FE69ED0E-0232-406F-8712-16A92F55C53A@postgrespro.ru

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: r.zharkov@postgrespro.ru, michael@paquier.xyz, tgl@sss.pgh.pa.us, bachow@microsoft.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: Intermittent pg_ctl failures on Windows
  In-Reply-To: <FE69ED0E-0232-406F-8712-16A92F55C53A@postgrespro.ru>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox