On Thu, Dec 14, 2017 at 8:42 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Dec 13, 2017 at 8:19 PM, Thomas Munro
> <thomas.munro@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