From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Add ANALYZE into regression tests |
Date: | 2014-04-14 03:28:22 |
Message-ID: | 19105.1397446102@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Greg Stark (stark(at)mit(dot)edu) wrote:
>> But the original goal seems like it would be easier and better done with an
>> immutable function which lies and calls elog to leak information. That's
>> the actual attack this is supposed to protect against anyways.
> Sure, but there's a whole slew of tests that would have to change if we
> changed the explain output, not just this one.
Sure, but I think Greg's point is that this could be tested by a
black-box functional test ("does it print something it shouldn't")
rather than a white-box test that necessarily depends on a whole lot
of *other* planner choices that don't have much to do with the point
in question. You already got bit by variances in the choice of join
type, which is not what the test is about.
I think the test is okay as-is as long as we don't see more failures
from it; but if we do see any more I'd suggest rewriting as per Greg's
suggestion rather than trying to constrain the plan choice even more
narrowly.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-04-14 03:35:48 | Re: [COMMITTERS] pgsql: Add ANALYZE into regression tests |
Previous Message | Stephen Frost | 2014-04-14 00:41:15 | Re: pgsql: Add ANALYZE into regression tests |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-04-14 03:35:48 | Re: [COMMITTERS] pgsql: Add ANALYZE into regression tests |
Previous Message | Robert Haas | 2014-04-14 01:15:42 | Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb |