From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: currawong is not a happy animal |
Date: | 2014-01-21 16:15:18 |
Message-ID: | CA+TgmoZYjfiy-m9WfJtOJh6mbFtg5FkPG-AWsz24AP6VJ1CkmA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 18, 2014 at 11:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-01-21 16:17:00 | Re: Custom collations, collation modifiers (eg case-insensitive) |
Previous Message | Magnus Hagander | 2014-01-21 16:10:10 | Re: proposal: hide application_name from other users |