Re: logical changeset generation v4
От | Andres Freund |
---|---|
Тема | Re: logical changeset generation v4 |
Дата | |
Msg-id | 20130115154922.GJ5115@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: logical changeset generation v4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: logical changeset generation v4
|
Список | pgsql-hackers |
On 2013-01-15 10:28:28 -0500, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On 2013-01-15 09:56:41 -0300, Alvaro Herrera wrote: > >> Oh, hm. Maybe the contrib module's make installcheck, then? > > > Thats what I do right now, but I really would prefer to have it checked > > during normal make checks, installchecks aren't run all that commonly :( > > Sure they are, in every buildfarm cycle. I don't see the problem. > > (In the case of contrib, make installcheck is a whole lot faster than > make check, as well as being older. So I don't really see why you > think it's less used.) Oh. Because I was being dumb ;). And I admittedly never ran a buildfarm animal so far. 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+. Is there a problem of making those the default in the buildfarm created config? I guess there would need to be an alternative output file for wal_level < logical? Afaics there is no way to make a test conditional? I shortly thought something like DO $$ BEGIN IF current_setting('wal_level') != 'df' THEN RAISE FATAL 'wal_level needs to be logical'; END IF; END $$; could be used to avoid creating a huge second output file, but we can't raise FATAL errors from plpgsql. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: