On Fri, Jun 8, 2018 at 11:00 PM, Magnus Hagander <mag...@hagander.net> wrote: > > On Fri, Jun 8, 2018 at 4:55 AM, Amit Kapila <amit.kapil...@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
