Re: Portability issues in shm_mq - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Portability issues in shm_mq
Date
Msg-id 12578.1395159328@sss.pgh.pa.us
Whole thread Raw
In response to Re: Portability issues in shm_mq  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Portability issues in shm_mq  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Portability issues in shm_mq  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> First, can you retest this with the latest code?

Yeah, on it now.

> If we want to inject some randomness into the test, which parameters
> do we want to randomize and over what ranges?

I think the message length is the only particularly interesting
parameter.  It'd be nice if the length varied *within* a test, but
that would take rather considerable restructuring, so maybe it's
not worth the trouble.

> Also, if a buildfarm
> critter falls over, how will we know what value triggered the failure?

Maybe we won't, but I think knowing that it does fail on platform X is
likely to be enough to find the problem.

>  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.

> 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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Patch: show relation and tuple infos of a lock to acquire
Next
From: Simon Riggs
Date:
Subject: Re: pg_archivecleanup bug