Re: Loaded footgun open_datasync on Windows

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Loaded footgun open_datasync on Windows
Date: 2018-06-11 01:19:18
Message-ID: 20180611011918.GE7066@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 10, 2018 at 10:09:26AM +0530, Amit Kapila wrote:
> As per discussion till now, we have two options to proceed:
> (a) Remove the define "#ifndef FRONTEND" that prevents pgwin32_open
> usage in frontend modules. We have done some research and found that
> it was added in the past to allow build of modules like libpq/psql.
> If we want to use this option, then some work is needed to ensure all
> frontend modules work/behave correctly.
> (b) Use c.h in pg_test_fsync which will allow usage of pgwin32_open.
> Option (a) appears to be a good approach, but I am not sure what exact
> tests would be required.

pg_upgrade could be a good match here by removing the stuff around
SERVER_START_LOG_FILE and SERVER_STOP_LOG_FILE in pg_upgrade.h and that
can run with a single command using vcregress.bat.

> Do you prefer any of the above or have any better suggestions?

(a) looks like a good plan to me, as long as there is no back-patch as
the result patch would be likely invasive. I would also suggest for v12
to open for commits.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-06-11 01:38:14 Re: SHOW ALL does not honor pg_read_all_settings membership
Previous Message Michael Paquier 2018-06-11 00:48:10 Re: pgsql: Fix and document lock handling for in-memory replication slot da