Re: shared memory message queues

On Wed, Jan 15, 2014 at 12:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jan 14, 2014 at 9:28 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>>> Something is causing this new compiler warning:
>>>
>>> setup.c: In function ‘setup_dynamic_shared_memory’:
>>> setup.c:102:3: error: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘Size’ [-Werror=format=]
>
>> Oops. I've pushed a fix (at least, I hope it's a fix).
>
> Unless I'm misreading what you did, that will just move the problem to
> a different set of platforms. size_t is not necessarily "long" (one
> counterexample is Win64, IIRC).
>
> In the past we've usually resorted to explicitly casting. You could
> silence the warning correctly with either of
> ereport("... %lu ...", (unsigned long) shm_mq_minimum_size);
> ereport("... " UINT64_FORMAT " ...", (uint64) shm_mq_minimum_size);
>
> However, the problem with the second one (which also existed in your
> original code) is that it breaks translatability of the string, because
> any given translator is only going to see the version that gets compiled
> on their hardware. Unless there's a significant likelihood of
> shm_mq_minimum_size exceeding 4GB, I'd go with the first one.

I think the current value is about 56, and while the header might
expand in the future, 4294967296 would be a heck of a lot of header
data. So I've changed it as you suggest. I think.

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