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. It's not
absolutely essential, because an extension can do something like what
test_shm_mq does to assign worker numbers based on order of startup,
but it's certainly useful.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
