access/parallel.h lacks PGDLLIMPORT
Hi hackers,
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.
--
Thomas Munro
http://www.enterprisedb.com
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
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
Attachments:
dllimport_parallelworkernum_v1.patchapplication/octet-stream; name=dllimport_parallelworkernum_v1.patchDownload
diff --git a/src/include/access/parallel.h b/src/include/access/parallel.h
index f4db882..5561cf8 100644
--- a/src/include/access/parallel.h
+++ b/src/include/access/parallel.h
@@ -52,7 +52,7 @@ typedef struct ParallelWorkerContext
} ParallelWorkerContext;
extern volatile bool ParallelMessagePending;
-extern int ParallelWorkerNumber;
+extern PGDLLIMPORT int ParallelWorkerNumber;
extern bool InitializingParallelWorker;
#define IsParallelWorker() (ParallelWorkerNumber >= 0)
On Tue, Dec 19, 2017 at 3:36 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
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.
I think waiting for a "really good" use case is too high a bar. I
think we only need to think that there is a "reasonable" use case.
Accordingly, I pushed a commit adding PGDLLIMPORT to both
ParallelWorkerNumber and InitializingParallelWorker.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 19 December 2017 at 23:24, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Dec 19, 2017 at 3:36 AM, Amit Kapila <amit.kapila16@gmail.com>
wrote: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.I think waiting for a "really good" use case is too high a bar. I
think we only need to think that there is a "reasonable" use case.
Accordingly, I pushed a commit adding PGDLLIMPORT to both
ParallelWorkerNumber and InitializingParallelWorker.
Especially since all non-static *functions* are exported unconditionally,
so it's not like we set a high bar for public API.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services