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

In response to

Responses

Browse pgsql-hackers by date

  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