Re: currawong is not a happy animal

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

In response to

Browse pgsql-hackers by date

  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