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>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: Portability issues in shm_mq |
Date: | 2014-03-18 16:15:28 |
Message-ID: | 12578.1395159328@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:
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2014-03-18 16:17:53 | Re: pg_archivecleanup bug |
Previous Message | Robert Haas | 2014-03-18 16:15:26 | Re: Patch: show relation and tuple infos of a lock to acquire |