On 04/13/2014 12:42 AM, Stephen Frost wrote:
Add ANALYZE into regression tests
Looks like we can end up with different plans happening on the
buildfarm, which breaks the regression tests when we include
EXPLAIN output (which is done in the regression tests for
updatable security views, to ensur
* Andrew Dunstan (and...@dunslane.net) wrote:
> Are you really sure we can do this consistently? The regression
> tests have to run against all sorts of settings, including those we
> have no control over via installcheck.
Sure? No. However, there are quite a few existing regression tests
that d
On 04/13/2014 08:48 AM, Stephen Frost wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
Are you really sure we can do this consistently? The regression
tests have to run against all sorts of settings, including those we
have no control over via installcheck.
Sure? No. However, there are q
Suppress compiler warning in new contrib/pg_trgm code.
MSVC doesn't seem to like it when a constant initializer loses
precision upon being assigned.
David Rowley
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/46a60abfe9fa13087dbbe15953c20df35f006968
Modified Files
Improve some O(N^2) behavior in window function evaluation.
Repositioning the tuplestore seek pointer in window_gettupleslot() turns
out to be a very significant expense when the window frame is sizable and
the frame end can move. To fix, introduce a tuplestore function for
skipping an arbitrary
Yeah I think this is OK.
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.
That would make the tests more robust against other changes
Greg,
* Greg Stark (st...@mit.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.
Uh, yes, that's what the explain is a
Stephen Frost writes:
> * Greg Stark (st...@mit.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 ther
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> 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
