Re: dsm use of uint64

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dsm use of uint64
Date: 2013-10-28 16:17:48
Message-ID: CA+TgmoZs7FtBgKx4gZGYuvamjr=MOjuTFoHpP912bx1c3QVYyw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 27, 2013 at 11:34 PM, Noah Misch <noah(at)leadboat(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rodolfo Campero 2013-10-28 16:22:29 Re: PL/Python: domain over array support
Previous Message Andres Freund 2013-10-28 16:17:46 Re: logical changeset generation v6.2