On Fri, Jun 8, 2018 at 11:00 PM, Magnus Hagander <magnus@hagander.net> wrote:
>
> On Fri, Jun 8, 2018 at 4:55 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>>
>> -#include "postgres_fe.h"
>> +#include "postgres.h"
>>
>> I don't think that server application can use backend environment unless
>> it is adapted to do so. I think the application should have the capability
>> to deal with backend stuff like ereport, elog etc, if we don't want to use
>> FRONTEND environment. The other server applications like pg_ctl.c,
>> initdb.c, etc. also uses FRONTEND environment.
>>
>
> Not having researched this particular case but yes, there are a number of
> things expected in a non-FRONTEND environment. Things that may also go
> unnoticed until too late (e.g. singal handling etc that needs explicit
> initialization). Standalong binaries should pretty much always be frontend.
>
Right, but here we are facing a situation where using FRONTEND in a
standalone binary (pg_test_fsync) won't accomplish the required
purpose. Basically, we want to use pgwin32_open (pg specific
implementation for open on windows) in pg_test_fsync and that is
protected by "#ifndef FRONTEND". 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. Do you prefer any of the above or have any
better suggestions?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com