On 2013-01-15 11:10:22 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > But the other part of the problem is hiding in the unfortunately removed
> > part of the problem description - the tests require the non-default
> > options wal_level=logical and max_logical_slots=3+.
>
> Oh. Well, that's not going to work.
An alternative would be to have max_logical_slots default to a low value
and make the amount of logged information a wal_level independent
GUC that can be changed on the fly.
ISTM that that would result in too complicated code to deal with other
backends not having the same notion of that value and such, but its
possible.
> > Is there a problem of making those the default in the buildfarm created
> > config?
>
> Even if we hacked the buildfarm script to do so, it'd be a nonstarter
> because it would cause ordinary manual "make installcheck" to fail.
I thought we could have a second expected file for that case. Not nice
:(
> I think the only reasonable way to handle this would be to (1) make
> "make installcheck" a no-op in this contrib module, and (2) make
> "make check" work, being careful to start the test postmaster with
> the necessary options.
Youre talking about adding a contrib-module specific make check or
changing the normal make check's wal_level?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
