Обсуждение: 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
Вложения
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.