Re: Portability issues in shm_mq

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Portability issues in shm_mq
Date: 2014-03-16 15:26:16
Message-ID: 25620.1394983576@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 Fri, Mar 14, 2014 at 4:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> How is that leading to a crash? Well, this machine is 32-bit, so MAXALIGN
>> is only 4. This means it is possible for an odd-length message cum
>> message length word to not exactly divide the size of the shared memory
>> ring buffer, resulting in cases where an 8-byte message length word is
>> wrapped around the end of the buffer.

> Argh. I think I forced the size of the buffer to be MAXALIGN'd, but
> what it really needs is to be a multiple of the size of uint64.

After sleeping on it, I think what you're proposing here is to double down
on a wrong design decision. ISTM you should change the message length
words to be size_t (or possibly ssize_t, if you're depending on signed
arithmetic), which would let you keep using MAXALIGN as the alignment
macro. There is absolutely no benefit, either for performance or code
readability, in forcing 32-bit machines to use 64-bit message length
words. Indeed, by not using the same alignment macros as everywhere else
and not being able to use %zu for debug printouts, I think the only real
effect you're producing is to make the DSM/MQ stuff more and more randomly
unlike the rest of Postgres. Please reconsider while it's still not too
late to change those APIs.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-03-16 15:39:24 Re: create type- similar char
Previous Message Greg Stark 2014-03-16 14:47:29 Re: [RFC] What should we do for reliable WAL archiving?