Re: dsm use of uint64 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: dsm use of uint64
Date
Msg-id CA+TgmoZs7FtBgKx4gZGYuvamjr=MOjuTFoHpP912bx1c3QVYyw@mail.gmail.com
Whole thread Raw
In response to Re: dsm use of uint64  (Noah Misch <noah@leadboat.com>)
Responses Re: dsm use of uint64  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Sun, Oct 27, 2013 at 11:34 PM, Noah Misch <noah@leadboat.com> wrote:
> On Fri, Oct 25, 2013 at 10:11:41PM -0400, Robert Haas wrote:
>> When I wrote the dynamic shared memory patch, I used uint64 everywhere
>> to measure sizes - rather than, as we do for the main shared memory
>> segment, Size.  This now seems to me to have been the wrong decision;
>> I'm finding that it's advantageous to make dynamic shared memory
>> behave as much like the main shared memory segment as is reasonably
>> possible, and using Size facilitates the use of MAXALIGN(),
>> TYPEALIGN(), etc. as well as things like add_size() and mul_size()
>> which are just as relevant in the dynamic shared memory case as they
>> are for the main shared memory segment.
>>
>> Therefore, I propose to apply the attached patch.
>
> +1.

OK, committed.

> The simplicity of platform-independent type sizing had some attraction,
> but not so much to justify this sort of friction with the rest of the system.

That's a good way of putting it.  I'm repeatedly learning - invariably
the hard way - that everything the main shared memory segment is or
does needs a parallel for dynamic shared memory, and the closer the
parallel, the better.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: OSX doesn't accept identical source/target for strcpy() anymore
Next
From: Andres Freund
Date:
Subject: Re: logical changeset generation v6.2