On Tue, Mar 18, 2014 at 12:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
>
> Meh. I think you're putting a bit too much faith in your ability to
> predict the locus of bugs that you think aren't there.
Well, I'm open to suggestions.
>> maybe at a test where the queue is smaller than the message size, so
>> that every message wraps (multiple times?).
>
> Does the code support messages larger than the queue size? If so, yes,
> that case clearly oughta be tested.
Yep. You should be able to send and receive any message that fits
within MaxAllocSize on even the smallest possible queue. Performance
may suck, but if that's an issue for you then don't use such a blasted
small queue. The intended use of this is to stream (potentially long)
error messages or (potentially long and numerous) tuples between
cooperating backends without having to preallocate space for all the
data you want to send (which won't be any more feasible in a DSM than
it would be in the main segment).
Actually, you should be able to send or receive arbitrarily large
messages if you change the MemoryContextAlloc call in shm_mq.c to
MemoryContextAllocHuge, but I can't see any compelling reason to do
that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
