Re: shared memory message queues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: shared memory message queues
Date: 2014-01-15 17:39:28
Message-ID: 28340.1389807568@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

If you really want to be able to print values >4GB in translatable
messages, what you need to do is to print into a local string variable
with UINT64_FORMAT, then use %s in the translatable string. There's
examples of this in commands/sequence.c among other places.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-01-15 17:43:04 Re: Changeset Extraction v7.0 (was logical changeset generation)
Previous Message Claudio Freire 2014-01-15 17:06:00 Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance