On Sat, Jan 18, 2014 at 11:54 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapil...@gmail.com> writes: >> Is there any specific reason why adding PGDLLIMPORT for exporting >> const variables is not good, when we are already doing for other variables >> like InterruptHoldoffCount, CritSectionCount? > >> On searching in code, I found that for few const variables we do >> extern PGDLLIMPORT. For example: >> extern PGDLLIMPORT const int NumScanKeywords; > > OK, that one is a direct counterexample to my worry. > > I'm still unconvinced that having a contrib module checking stuff based > on the size of a struct it's not supposed to access represents a sane > division of responsibilities; but let's fix the build problem now and > then Robert can contemplate that question at his leisure.
Exposing the whole struct because of that minor detail seemed really ugly to me, and I feel strongly that we should avoid it. In the intended use of this code, I expect queues to be some number of kilobytes on the low end up to some number of megabytes on the high end, so the fact that it can't be less than 56 bytes or so is sort of a meaningless blip on the radar. So one thing I thought about is just defining the minimum size as something conservative, like 1024. But for testing purposes, it was certainly useful to create the smallest possible queue, because that stresses the synchronization code to the maximum degree possible. So on the whole I'm still happy with how I did this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers