Re: Portability issues in shm_mq

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: Portability issues in shm_mq
Date: 2014-03-18 16:04:50
Message-ID: CA+Tgmoa6kq-M7DpEWTm1fCCimjDD-+wsHQH_24Xo72=iKPdvtQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

All right.

On Fri, Mar 14, 2014 at 4:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Whilst setting up a buildfarm member on an old, now-spare Mac, I was
> somewhat astonished to discover that contrib/test_shm_mq crashes thus:
> TRAP: FailedAssertion("!(rb >= sizeof(uint64))", File: "shm_mq.c", Line: 429)
> but only in UTF8 locales, not in C locale. You'd have bet your last
> dollar that that code was locale-independent, right?

First, can you retest this with the latest code?

> Recommendations:
>
> 1. Reduce the random() multiplier from 96 to 95. In multibyte encodings
> other than UTF8, chr() would flat out reject values of 128, so this test
> case is unportable.
>
> 2. Why in the world is the test case testing exactly one message length
> that happens to be a multiple of 8? Put some randomness into that,
> instead.
>
> 3. Either you need to work a bit harder at forcing alignment, or you need
> to fix shm_mq_receive to cope with split message length words.
>
> 4. The header comment for shm_mq_receive_bytes may once have described its
> API accurately, but that appears to have been a long long time ago in a
> galaxy far far away. Please fix.

On these recommendations, I believe that #3 and #4 are now dealt with.
That leaves #1 and #2. #1 is of course easy, but I think we should
do them both together.

If we want to inject some randomness into the test, which parameters
do we want to randomize and over what ranges? Also, if a buildfarm
critter falls over, how will we know what value triggered the failure?
It's tempting to instead add one or more tests that we specifically
choose to have values we think are likely to exercise
platform-specific differences or otherwise find bugs - e.g. just add a
second test where the queue size and message length are both odd. And
maybe at a test where the queue is smaller than the message size, so
that every message wraps (multiple times?).

Thoughts?

--
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 Robert Haas 2014-03-18 16:12:21 Re: Patch: show relation and tuple infos of a lock to acquire
Previous Message Peter Eisentraut 2014-03-18 16:03:55 Re: Minimum supported version of Python?