On Thu, Dec 14, 2017 at 8:42 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Dec 13, 2017 at 8:19 PM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> I suppose that extensions are supposed to be allowed to use the >> facilities in access/parallel.h. I noticed in passing when I wrote a >> throwaway test harness that my Windows built drone complained: >> >> test_sharedtuplestore.obj : error LNK2001: unresolved external symbol >> ParallelWorkerNumber >> [C:\projects\postgres\test_sharedtuplestore.vcxproj] >> .\Release\test_sharedtuplestore\test_sharedtuplestore.dll : fatal >> error LNK1120: 1 unresolved externals >> [C:\projects\postgres\test_sharedtuplestore.vcxproj] >> >> I suppose that all three of these might need that, if they're part of >> the API for parallel worker management: >> >> extern volatile bool ParallelMessagePending; >> extern int ParallelWorkerNumber; >> extern bool InitializingParallelWorker; >> >> I'm less sure about the other two but at least ParallelWorkerNumber is >> essential for anything that needs to coordinate access to input/output >> arrays or similar. > > I can't really think of a reason for extensions to need to access > ParallelMessagePending. InitializingParallelWorker could be useful if > the extension is doing something strange with custom GUCs. > ParallelWorkerNumber is useful for the reason you state. >
I also think it is good to allow ParallelWorkerNumber to be used in extensions. Attached is the patch for same. I think for other two we should wait till there is really a good use case for them. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
dllimport_parallelworkernum_v1.patch
Description: Binary data
