Re: Intermittent pg_ctl failures on Windows - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Intermittent pg_ctl failures on Windows
Date
Msg-id 20190719030208.GG1859@paquier.xyz
Whole thread Raw
In response to Re: Intermittent pg_ctl failures on Windows  (Жарков Роман <r.zharkov@postgrespro.ru>)
Responses Re: Intermittent pg_ctl failures on Windows  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Intermittent pg_ctl failures on Windows  (Жарков Роман <r.zharkov@postgrespro.ru>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: SegFault on 9.6.14
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Support for CALL statement in ecpg