Re: Intermittent pg_ctl failures on Windows

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Жарков Роман <r(dot)zharkov(at)postgrespro(dot)ru>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Badrul Chowdhury <bachow(at)microsoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Intermittent pg_ctl failures on Windows
Date: 2019-07-19 03:02:08
Message-ID: 20190719030208.GG1859@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2019-07-19 03:03:08 Re: Support for CALL statement in ecpg
Previous Message Amit Kapila 2019-07-19 03:00:42 Re: SegFault on 9.6.14