Re: currawong is not a happy animal - Mailing list pgsql-hackers

From Robert Haas
Subject Re: currawong is not a happy animal
Date
Msg-id CA+TgmoZYjfiy-m9WfJtOJh6mbFtg5FkPG-AWsz24AP6VJ1CkmA@mail.gmail.com
Whole thread Raw
In response to Re: currawong is not a happy animal  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Jan 18, 2014 at 11:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapila16@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



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: proposal: hide application_name from other users
Next
From: Alvaro Herrera
Date:
Subject: Re: Custom collations, collation modifiers (eg case-insensitive)